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PREFACE 



This manual is a definitive description of the BLISS language as 
implemented for the PDP-1 0, BLISS is a language specifically designed for 
writing software systems such as compilers and operating systems for the 
PDP-1 0, While much of the language is relatively "machine independent" and 
could be implemented on another machine, the PDP-1 was always present in 
our minds during the design, and as a result BLISS can be implemented very 
efficiently on the 10, This is probably not true for other machines. 

We refer to BLISS as an "implementation language". This phrase has 
become quite popular lately, but apparently does not have a uniform meaning. 
Hence it is worthwhile to explain what we mean by the phrase and consequently 
what our objectives were in the language's design. To us the phrase "imple- 
mentation language" connotes a higher level language suitable for writing 
production software; a truly successful implementation language would 
completely remove the need and /or desire to write in assembly language. 
Furthermore, to us, an implementation language need not be machine inde- 
pendent — in fact, for reasons of efficiency, it is unlikely to be. 

Many reasons have been advanced for the use of a higher level language 
for implementing software. One of the most often mentioned is that of speed- 
ing up its production. This will undoubtedly occur, but it is one of the less 
important benefits, except insofar as it permits fewer, and better program- 
mers to be uged. Far more important, we believe, are the benefits of docu- 
mentation, clarity, correctness and modifiability. These were the most 
important goals in the design of BLISS, 

Some people, when discussing the subject of implementation languages, 
have suggested that one of the existing languages, such as PL/i, or at most 



a derivative of one, should be used; they argue that there is already a pro- 
liferation of languages, so why add another. The only rational excuse for 
the creation of yet another new language is that existing languages are ^) 

unsuitable for the specific applications in mind. In the sense that all 
languages are sufficient to model a Turing machine, any of the existing 
languages, LISP for example, would be adequate as an implementation language. 
However, this does not imply that each of these languages would be equally 
convenient. For example, FORTRAN can be used to write list processing pro- 
grams, but the lack of recursion coupled with the requirement that the pro- 
grammer code his own primitive list manipulations and storage control makes 
FORTRAN vastly inferior to, say, LISP for this type of programming. 

What, then, are the characteristics of systems programming which should 
be reflected in a language especially suited for the purpose? Ignoring 
machine dependent features (such as a specific interrupt structure) and 
recognizing that all differences in such programming characteristics are 
only ones of degree, three features of systems programming stand out: 

1. Data structures. In no other type of programming does the 
variety of data structures nor the diversity of optimal 
representations occur. 

2. Control structures. Parallelism and time are intrinsic 
parts of the programming system problem.* 

3. Frequently, systems programs cannot presume the existence 
of large support routines (for dynamic storage allocation, 
for example). 



* 



Of course, parallelism and time are intrinsic to real time programming 
as well. 
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These are the principal characteristics which the design of BLISS 
attempts to address. For example, taking point (3), the language was 
designed in such a way that no system support is presumed or needed, 
even though, for example, dynamic storage allocation is provided. Thus, 
code generated by the compiler can be executed directly on a "bare" 
machine. Another example, taking point (1), is the data structure defini- 
tion facility. BLISS contains no implicit data structures (and hence no 
presumed representations for structures) , but rather provides a method 
for defining a representation by giving the explicit accessing algorithm. 

One final point before proceeding with the description of the lan- 
guage — namely, the method of syntax specification. The syntax is given 
in BNF, for example 

escapeexpression -^ EXITBLOCK escapeexpression| EXITLOOP escapeexpression 
escapeexpression -» ] e 

where: (1) lower case words are metalinguistic variables, and (2) the 
* empty* construct is represented by a blank (as in the first alternative 
of the second rule above) , 
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1.1 



I, LANGUAGE DEFINITION 

1.1 Modules 

A module Is a program element which may be compiled independently of 
other elements and subsequently loaded with them to form a complete program. 

module -♦ MODULE name (parameters) = e ELUDOM 

A module may request access to other modules' variables and functions by 
declaring their names in EXTERNAL declarations. A module pennits general 
use of its own variables and ROUTINES by means of GLOBAL declarations. 
These lines of communication between modules are linked by the loader prior 
to execution. A complete program consists of a set of compiled modules 
linked by the loader. 

Tlie 'name' in a module declaration is used to identify that module 
and must be unique in its first four characters from any other global 
names which are to be linked together to form a complete program. The 
'parameters' field of a module definition is us6d to control the compila- 
tion (see section II. 1.4). See section IV-1.3 for other uses of the module 
name. 
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1.2 Blocks and Comments 

A block is an arbitrary number of declarations followed by an arbi- 
trary number of expressions all separated by semicolons and enclosed in a 
matching begin-end or '('-')' pair. 

block -► BEGIN blockbody END | (blockbody) 

compoundexpression -» BEGIN expressionsequence END | (expressionsequence) 

blockbody -^ declarations; expressionsequence 

declarations -+ declaration | declaration; declarations 

expressionsequence -♦ | e | e; expressionsequence 

comment -♦ | I restofline endoflinesymbolj '^ stringwithnopercent 'i 

Comments may be enclosed between the sjnnbol \ and the end of the line on 

which the I appears. However, a I may appear in the quoted string of a _J 

literal, or between two ^ symbols, without being considered the beginning 

of a comment. Likewise, a ^ enclosed within quotes will be considered part 

of a string. 

As in Algol the block indicates the lexical scope of the names declared 
at its head. However, in contrast to Algol, there is an exception. The 
names of GLOBAL variables and ROUTINES have a scope beyond the block and 
although they are declared within the module, the effect, for a module 
citing them in an EXTERNAL declaration, is as if they were declared in the 
current block. This violation of block structure has implications with 
respect to allowed references, particularly in connection with declared 
registers. These implications, and a corresponding set of restrictions, 
will be discussed in connection with the affected declarations. 
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1.3 Literals 

The basic data element is a PDP-10 36 bit word. However, the hard- 
ware provides the capability of pointing to an arbitrary contiguous field 
within a word and so a 36 bit word may be regarded as a special case of 
the "partial word". Literals are normally converted to a single word, 

literal -♦ number | quotedstring | plit 

number -» decimal | octal | floating 

decimal -* digit | decimal digit 

octal -♦ # oit I octal oit 

floating -* decimal. decimal | decimal. decimal exponcmt | decimal. exponent 

exponent -♦ E decimal | E + decimal | E - decimal 

digit -► 0|l|2 --- |9 

oit -* 0|l|2 -— |7 

36 
numbers (unsigned integers) are converted to binary modulo 2' residue 

35 
-2 . The binary number is 2's complement and is signed. Octal constants 

are prefixed by the sharp sign, #. Floating numbers must have an embedded 

decimal point and no embedded blanks'. 

quotedstring -* leftadjustedstring | rightadjustedstring 
leftadjustedstring -* 'string' 
rightadjustedstring -* "string" 

Quoted-string literals may be used to specify bit patterns corresponding to 
the 7 -bit ASCII code for visable graphic characters on the external l/o 
media. Two types of single-word strings are provided for left or right 
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justification of the string within a word. Normally quoted strings are 
limited to five characters and the unused bit positions are filled with 
zeroes. 

Within a quoted string the quoting character is represented by two 
successive occurrences of that character. 
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1.3.1 



1,3.1 Pointers to Literals - "plit"8 

A plit is a pointer to a lite ral word whose contents are specified at 

compile time; e.g., plit 3 is a pointer to a word whose contents will be 
set to 3 at load time. 

pll^ ~* plit plitarg 
plitarg -* load-time-expression j 
long-string | 
triple 
triple -* (triple-itera-list) 

triple-item-list -♦ triple-item | triple-item, triple-item-list 
triple-item -* load -time -express ion | 
long-string | 

duplication-factor: plitarg 
f ) duplication-factor -♦ compile-time-expression 

Note: " plit (3)+4" has 2 parses: plit load -time -express ion 

^^^ plit triple + expression 

The latter choice is used. Hence, "plit (3)44" is the same 
as "( plit 3)-l4". 

A plit may point to a contiguously stored sequence of literals - 
long strings and nested lists of literals are also allowed. The value of 

plit (3,5,7,9) 

is a pointer to 4. contiguous words containing 3,5,7 and 9 respectively. 
A long string (> 5 characters) is also a valid argument to a plit: 

plit 'THIS ALLOCATES 5 WORDS' 
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allocates 5 words of 7 -bit ASCII characters with 3 pad characters of zero 
to the right and the last bit turned on. 

The arguments to plits need only be constant at load time; plits are 
themselves literals, thus nesting of plits is allowed (with the inner plits 
allocated first) : 

external A,B,C; 

bind y = plit (A, plit (B,C), plit 3, 'A LONG STRING', 5+9*3); 

is such that: 

.y[0] = A<0,36>; ..y[l] = B<0,36>; .(.y[l]+l) = C<0,36> 
..y[2] = 3; .y[3] = 'A LON' ; .y[4] = 'G STR' ; .y[5] = 'ING' or 1; 
.y[6] = 32; 

In addition, any argument to a plit can be replicated by specifying 
the number of times it is to be repeated; e.g. 

plit (7:3) 

produces a pointer to 7 contiguous words, each of which contains the value 3. 
Duplicated plits are allocated once, identical plits are not pooled - hence, 

bind X = plit (3: plit A, plit A, 2: (2,3)); 

is such that: 

..x[0] == ..x[l] « ..x[2] = ..x[3] = A<0,36>; 
.x[0] « .x[l] = .x[2] ^ .x[3]; 
.x[4] ^ .x[6] - 2; .x[5] = .x[7] - 3; 

O 

Note: the length of every plit (in words) is stored as the word preceding 
the plit. Hence, in the last example, .x[-l] « 8, 
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1.4 Names 

Syntactically an identifier, or name, is composed of a sequence of 
letters and/or digits, the first of which must be a letter. Certain names 
are reserved as delimiters, see Appendix A. Semantically the occurrence 
of a name is exactly equivalent to the occurrence of a pointer to the named 
item. The term "pointer" will take on special connotation later with 
respect to contiguous sub-fields (bytes) within a word; however, for the 
present discussion the term may be equated with "address". This interpre - 
tation of name is uniform throughout the language and there is no distinc - 
tion between left and right hand values . Contrast this with Algol where a 
name usually, but not always, means "contents of". 

The pointer interpretation requires a "contents of" operator, and "." 
has been chosen. Thus .A means 'fcontents of location A" and ..A means 
"contents of the location whose name is stored in location A\ To illustrate 
the concept, consider the assignment expression 

pll ♦- e 

This means 'fetore the value computed from e into the location whose pointer 
is the value of pll". (Further details are given in 2.2.) Thus the Algol 
statement "A := B" is written "A <- .B". It is impossible to express in 
Algol BLISS expressions such as: "A «- B", "A «- ..B", ".A «- .B", etc. 
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1.5 Pointers 

As explained in 1.4, the value of a name is a pointer which names a 
location in memory. However, pointers are more general than mere ad- 
dresses since they may name an arbitrary contiguous portion of a word, and 
may, further, involve index modification and indirect addressing, (For 
full details, the reader should refer to the PDP-10 System Reference 

Manual.) The most general form of pointer specifies five quantities; an 

18 
example is €« <€, , C » €« , €,>, where € is computed modulo 2 and forms 



th 



e base word address (Y field); €,,€«, are computed modulo 2 and form 



the position, size fields respectively (P, S fields); € is computed 

4 
modulo 2 and forms the index field (X field); €, is computed modulo 2 

and forms the indirect address bit (I field). Each of €-|,€2»€^>€> may 

optionally be omitted, in which case a default value is supplied, ^i»^>^a 

have defaults of 0, but ^ has the default of 36, Thus, for example, 

the expression 

(x+l)<.y,3> 

defines a three bit field in the first location beyond x. Thie position 
of this three bit field is ".y" bits from the right end of the word. 
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location "x" 



location "x+1' 






■^ ^N" bits 
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1 .6 The "contents of" Operators 

The interpretation placed on identifiers in Bliss coupled with the dot 
operator discussed earlier allow a programmer direct access to, and control 
over, fields within words, to pointers to such fields which are themselves 
stored within memory, to chains of such pointers i etc. Two additional 
"contents of" operations besides the dot are provided which are more effi- 
cient in certain cases, but which are defined in terms of the dot and 
pointer operations. These operators are @ and\, and are defined by the 
following (where, t is a temporary) : 

@€ = .€ < 0, 36, 0, > 

\^ = .(t <~ €) < 0, 36, .t < 18, 4 >, .t < 22, 1 » 

Thus, both @6 and \€ specify a full 36 bit value. @6 uses only the right- 
most 18 bits of € as the absolute address from which to fetch the value. 
\G interprets the rightmost 23 bits of € as an indirect bit, index register 
field and base address. Whichever form is used, the compiler attempts to 
optimize the code produced; thus, for example, identical code is produced 
for .X, @x, and \ X, if they occur in an expression. 

Suppose that the assignment "X <- Y < 3, 15, Rl , 0>;" has been executed, 
that is a pointer has been stored in X (that pointer has P=3, S=15, X=Rl , 
1=0), and further that register Rl contains two. Now: 

(1) Z «- .X stores the value of X, i.e., the pointer, into Z 

(2) Z <- ..X stores the value of the fifteen bit field (which ends three 

bits from the right) on the second word following Y into Z 

(3) Z <-@ .X stores the value of Y into Z 

(4) z <_\ .X stores the value of, the second word following Y into Z 

(5) .X «- 5 stores 5 into the relevant fifteen bit field of the second 

word following Y 
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2, 1 Expressions 

Every executable form in the BLISS language (that is, every form 
except the declarations) computes a value. Thus all commands are expres' 
sions and there are no "statements" in the sense of Algol or Fortran, 
In the syntax description e is used as an abbreviation for expression. 

e -* simpleexpression I controlexpression 
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2.2 Simple Expressions 

The semantics of simpleexpressions is most easily described in terms 
of the relative precedence of a set of operators, but readers should also 
refer to the BNF-like description in 4.1. The precedence number used 
below should be viewed as an ordinal, so that 1 means first and 2 second 
in precedence. In the following table the letter 6 has been used to denote 
an actual expression of the appropriate syntactic type, see 4.1. 



Precedence 


Example 


1 


compoundexpression 


1 


block 


1 


%^^V^""'^v} 


1 


name[€^,€2,... ,(E^] 


1 


name 



literal 

G^pointer paraineters> 
.€ 

<®€ 
\€ 

e^ MOD ^2 

-e 
e-e 



6,-62 



Semantics 

The component expressions are 
evaluated from left to right 
and. the final value is that of 
the last component expression. 

A function call, see 3.4. 

A structure access, see 3.5. 

A pointer to the named item, 
see 1.4, 

Value of the converted literal, 
see 1.3. 

A partial word pointer, see 1.5. 

Value (possibly partial word) 
pointed at by (: , 

Equivalent to . ^0.36.0. 0>- 

Equivalent to . (t<-€)< 0,36,,t< 18, 4>, 
.t<22,1». 

€, shifted logically by £^ bits; 

left if ^ positive; right if 

£- negative. (Shifts are modulo 256.) 

Product of €'s. 

€, divided by €^ . 

€, modulo 62* 

Negative of €. 

Sum of €'s. 

Difference between €^ and C* 



2.2a 



36 
[Note all integer arithmetic is carried out modulo 2 with a residue 

of -2 . ] 
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Precedence 
5 

5 

6 

6 

6 



Example 
€j FMPR ^ 

^^ FDVR ^2 

FNEG 6, 

€]^ FADR ^2 

€i FSBR ^2 



Semantics 
Floating product of 6^ and €«. 

Floating divide of €j by €« . 

Floating negate of G . 

Floating sum of €, and £-, 

Floating difference of G-i and G, 



€, EQL 62 
€^ NEQ ^2 
€, LSS €2 
€]L LEQ ^ 
€^ GTR €2 
€3^ GEQ €2 



[Truth is represented by 1, falsity by 0.] 

8 NOT € 

9 € AND € 

10 € OR € 

11 € XOR e 
11 € EQV € 

12 e-^ 



«! 


= ^ 


^1 


^^ 


^1 


<e. 


^1 


^^ 


^1 


>62 


% 


^^ 



bitwise complement of € 

bitwise and of €'s 

bitwise inclusive or of €'s 

bitwise exclusive or of €' s 

bitwise equivalence of €'s 

The value of this expression is 
identical to that of (L, but as 
a side effect this value is stored 
into the partial word pointed to 
by €^ ; with associative use of <-, 
the assignments are executed from 
right to left: thus ^-i *" ^ *" ^ 
means €, ♦- (C *" €3). 
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2.2b 



There Is no guarantee regarding the 
order in which a slmpleexpresslon is 
evaluated other than that provided by 
precedence and nesting; thus 
(R ♦- 2; @ R * (R *" 3)) may evaluate 
to 6 or 9. 



The reader should refer to the PDP-10 reference manual for a complete 
definition of the arithmetic operators under various special input value 
conditions. 
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2.3.1 Control Expressions 

The controlexpr ess ions provide sequencing control over the execution 
of his program; there are five forms: 

controlexpression -> conditionalexpression | loopexpression | 

choiceexpression | escapeexpression | coroutineexpression 

The general goto statement has deliberately been omitted from the 
language to improve readability and structuring of programs. 
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2.3.2 Conditional Expressions 

conditionalexpression -» IF e^ THEN e^ ELSE e» 

e^ is computed and the resulting value is tested. If it is odd*, then e« 
is evaluated to provide the value of the conditional expression, otherwise 
e, is evaluated. 

conditionalexpression -> IF e- THEN e 

This form is equivalent to the IF'-THEN-ELSE form with replacing e^. 
However, it does introduce the "dangling else" ambiguity. This is resolved 
by matching each ELSE to the most recent unmatched THEN as the conditional 
expression is scanned from left to right. 



r^ Only the least significant bit of e- is tested; a zero bit is interpreted as 

false and a one bit as true. Thus any odd integer value is interpreted as 



true and any even value as false. 
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2.3.3 Loop Expressions 

The value of each of the six loop expressions is -1, except when an 
EXITLOOP is used, see 2.3.4. 

loopexpression -* WHILE e^ DO e^ 

The e- is ccwnputed and the resulting value is tested. If it is odd, then 
e^ is computed and the complete loopexpression is recomputed; if it is evenj 
then the loopexpression evaluation is complete. 

loopexpression -» UNTIL e« DO e^ 

This form is equivalent to the WHILE -DO form except that e, is replaced by 



NOTCe^). 



loopexpression -» DO e^ WHILE e. 



The expressions e^je^ are computed in that sequence. The value resulting 
from e, ia tested: if it is odd, then the complete loop expression is 
recomputed; if it is even, then the loopexpression evaluation is complete. 

loopexpression -» DO e^ UNTIL e~ 
This form is equivalent to the DO-WHILE form except that e^ is replaced by 



NOTCe^). 



loopexpression ~» INCR name FROM e, TO e^ BY e^ DO e. 



This is a simplified form of the Algol 68 for-loop. The "name" is declared 
to be a REGISTER or a LOCAL for the scope of the loop. The expression e- is 
computed and stored in name. The expressions e« and e^ are computed and 
stored in unnamed local memory which for explanation purposes we shall name 
Vj and U^. Any of the phrases "FROM eJ' "To qJ* or "BY e^" may be omitted — 
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35 
in which case default values of e, - 0, e^ * 2 -1, e^ » 1 are supplied. 

The following loopexpression is then executed: 



BEGIN REGISTER name; LOCAL U2,U3; U2, «- e^; U3 «- e ; 

UNTIL .name GTR .U2 DO (e, ; name ♦- .name +,U3) 
END 

The final form of a loopexpression is: 

loopexpression -► DECK name FRCM e- TO e« BY e DO e. 

This is equivalent to the INCR-FROM-TO-BY-DO form except that the final 
loop is replaced by 

BEGIN REGISTER name; LOCAL U2,U3; U2 ♦- e2 ; U3 ♦- e ; 

UNTIL .name LSS .U2 DO (e, ; name «- .name - .U3) 
END 

If any of the FROM, TO, or BY phrases are omitted from a DECR expression, 

35 
default values of e,= 0, e^ = -2 , and e^ *= 1 are supplied. Notice that 

in both forms the end condition is tested before the loop, hence the loop 

is potentially executed zero or more times. 
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2.3.4 Escape Expressions 

The various forms of escapeexpressions permit control to leave its 
current environment. They are intended for those circumstances when other 
controlexpressions would have to be contorted to achieve the desired effect. 

escapeexpression -♦ environment level escapevalue | RETURN escapevalue 
environment -> EXIT | EXITBLOCK | EXITCOMPOUND | EXITLOOP | EXITCOND 
EXITCASE I EXITSET | EXITSELECT 

level -4 [ [fej 

escapevalue -♦ | e 

Each of these expressions conveys to its new environment a value, say 6, 
obtained by e-vJ^aluating the escapevalue, which may optionally be omitted imply- 
ing € = 0. The levels field, which must evaluate to a constant, say n, at 
compile time, determines the number of levels of the specified control environ- 
ment to be exited; the levels field may optionally be omitted in which case 
one level is implied. The maximum number of levels which may be exited in 
this way is limited by the current function (routine) body or the outermost block. 
RETURN terminates the current function, or routine, with value €. 

EXITBLOCK terminates the innermost n (where n is the value of the 
"levels" field) blocks, yielding a value of € for the 
outermost one exited. 

EXITCOMPOUND terminates the innermost n compound expressions, yielding 
a value of € for the outermost one exited. 

EXITLOOP terminates the innermost n loop expressions, yielding a 
value of € for the outermost one exited. 

EXITCOND terminates the innermost n conditional expressions, 
yielding a value of € for the outermost one exited. 

EXIT terminates the innermost n control scopes (whether blocks, 
compounds, conditionals, or loops with G as the value 
of the outermost. 
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EXITCASE terminates the n innermost case expressions yielding 
a value of € for the outermost of these. 

EXITSET terminates the n innermost set expressions, yielding a 
value of € for the outermost of these. 

EXITSELECT terminates the n innermost select expressions, yielding 
a value of 6 for the outermost of these. 
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2-3.5 Choice Expressions 

choiceexpression -♦ CASE elist OF SET expressionset TES 

elist -♦ e I e, elist 

expressionset -♦ |e|; expressionset | e ; expressionset 

Let us suppose that the actual e's within the elist are ^i>^»"«j€_ ^nd 

that the actual expressions within the expressionset are I1~;TI| ; , , , ;n. Then 

the expressions 11^ ,11- ,...II- are executed in that order. The value of 

^1 ^2 %a. 
the case expression is that of 11^ • 

choiceexpression -* SELECT elist OF NSET nexpressionset TESN 
nexpressionset -♦ | ne j ne; nexpressionset 

ne -♦ e:e 

This form is somewhat similar to the case expression except that the 
expressions in the nexpressionset are not thought of as being sequentially 
numbered --instead each expression in the nexexpressionset is tagged with an 
"activation" expression. Suppose we have the following select expression 

SELECT €]^, e^s €3 OF NSET ^r €5; 6^: €7; €g-. €9; ^-^^1 e^-^ TESN 

then the execution proceeds as follows: first €-,, ^, ^ are evaluated, 
then G» €^» €0 and 6, « are evaluated; correspondingly €c is evaluated if 
and only if €/ is equal to one of £,, ^, or €-s. Similarly €7 is evaluated 
if and only if €g is equal to one of €,, €2* or €o» etc. The order of 
comparison of 6a, ^, etc. is from left-to-right, and the value of the 
select expression is the last of €c» €y, etc. to be evaluated (or -1 if 
none is evaluated) . 
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In. place of one of the selection expressions, €, » C, etc. one of 
the two reserved words OTHERWISE or ALWAYS may be used, e.g., "ALWAYS: 6q". 
The expression following an "OTHERWISE:" will be executed just in the case 
that none of the preceding selection criteria were satisfied. The expres- 
sion following an "ALWAYS:" will always be executed independent of the 
selection criteria. In the following example 

z ♦- SELECT .x,.y OF 
NSET 

T.i 

3 
OTHERWISE: € 

36: ^ 

kWkXS: e 

94: €^ 

TESN; 

1 2 

(1) € will be executed if ,x=l or .y^l, then (2) € will be executed if 

3 I J. 

.x~7 oir .y=7, then (3) £ will be executed in the case neither ^ nor C" 

was executed, i.e., .259^1, .y?^!, .xji^7, and .y?^7, then (4) 6 will be executed 

5 6 

if .x=36 or .y=36, then (5) 6 will always be executed, and finally (6) 6 

will be executed if .x^94 or .y«94. The value assigned to z will be 

that of t unless .x=94 or .y=94 in which case the value assigned to z 

6 
will be that of € . 

Note that although OTHERWISE and ALWAYS may be placed in any nset -element, 

it makes no sense to use more than one OTHERWISE or to use an OTHERWISE 

after an ALWAYS since in these cases the latter OTHERWISE'S can have no 

(^ effect. 
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2.3.6 Co-routine Expressions 

The body of a function or routine may be activated as a co-routine 
and/or asynchronous process; the additional syntax Is 

coroutlneexpresslon -^ CREATE e. (ellst) AT e LENGTH e„ THEN e, | 

EXCHJ (e^ , e,) 
7 

The effect of a 'create* expression Is to create a context, that Is 
an Independent stack, for the routine (function) named by e. , with para- 
meters specified by the ellst, at the location whose address is specified by e^ and of 
size e^ words. Control then passes to the statements following the 'create'. When 
two or more such contexts have been established, control may be passed from 
any one to any other by executing an exchange- jump, EXCHJ. (a- , e^;, where the 
value of e^ must be the stack base, e„, of a previous 'create' expression. 
The value of ey is made available to the called routine as the value of its 
own EXCHJ which caused control to pass out of that routine. Thus the 
value of the EXCHJ operation is defined dynamically by the co-routine which 
at some later time re-activates execution of the current co-routine. 

Should a process, the body of which is necessarily that of a function 
(or routine), execute a 'return', either explicitly or implicitly, the ex- 
pression e, ''following the 'then' in the 'create' expression of the creating 
process) is executed in the context of the created process. The normal 
responsibilities of e, include making the stack space used for the created 
context available for other uses and performing an EXCHJ to some other 
process. 

The facilities described above, namely 'create' and 'exchj', are 
adequate either for use directly as co-routine linkages or for use as primi- 
tives in constructing more sophisticated co-routine facilities with macros 
_ — 

Note that the 1st EXCHJ to a newly created process causes control to enter 
from its head with actual parameters as set up by the CREATE. 

The value e-^ is not available to the called routine on the 1st EXCHJ to it. 
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and /or procetlures. It should be noted in the context that If the created 
processes are functions (rather than routines) the resulting processes con- 
tinue to have access to lexically global variables which may be local to an 
embracing function (access to lexically local variables which have been 
declared 'own' is available in either case). In such a case the resulting 
structure is a stack tree in which all segments of the tree below the 
lexical level of the (function) process are available to it. 

Two additional complexities are added if the create and exchj 
are to be used for asynchronous, and possibly parallel, execution of pro- 
cesses. One is synchronization, by which we man a mechanism by which a 
process can coordinate its execution with that of one or more others, A 
typical example of the need for synchronization occurs when two processes, 
\^ independently update a common data base, and each must be sure that the 

entire updating process is complete before any other process attempts to 
use the data base. The second complexity arises in connection with inter- 
rupts, and in particular from the fact that certain operations must not be 
interrupted (some exchj operations for example) . It is possible that cer- 
tain situations require synchronization mechanisms but do not need to be 
concerned about the interrupt problem — as for example, a user program with 
asynchronous processes, which is 'blind' to interrupts, and which some 
monitor systems view as a single 'job'. 

The nature of "appropriate" synchronization primitives and mechanisms 
for temporarily blinding the processor to interrupts (or interrupts in a 
certain class) are highly dependent upon the nature of the processes being 
used and the operating system, or lack of one, underlying the Bliss program. 
As a consequence, no syntax for dealing with either problem is included in 
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the language; in any case, the amount of code necessary for these facilities 
is quite small. 

The co-routine user is well advised to read and understand the material 
on the run- time representation of Bliss programs contained in section IV, 



D 



D 



3.1 



O 



O 



3.1 Declarations 

All declarations, except MAP and SWITCH, introduce names each of 
which is unique to the block in which the declaration appears. Except 
with STRUCTURE and MACRO declarations, the name introduced has a pointer 
bound to it. 

The declarations are: 

declaration -» functiondeclaration] structuredeclarationj 
binddeclaration|macrodeclaration| 
allocationdeclaration|mapdeclaration 

Before proceeding with a detailed discussion of the declarations 
we shall give an intuitive overview of the effect of these declarations. 
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3-l»l Storage (an introduction) 

A Bliss program operates with and on a number of storage "segments". 
A storage segment consists of a fixed and finite number of "words", each 
of which is composed of a fixed and finite number of "bits" (36 for the 
PDP-10). Any contiguous set of bits within a word is called a "field". 
Any field may be "named", the value of a name is called a "pointer" to 
that field. In particular, an entire word is a field and may be named. 

In practice a segment generally contains either program or data, 
and if the latter, it is generally integer numbers, floating point numbers, 
characters, or pointers to other data. To a Bliss program, however, a 
field merely contains a pattern of bits. 

Segments are introduced into a Bliss program by declarations, called 
allocation declarations, for example: J 

global g; 

own x,y [5], z; 

local p [100]; 

register rl, r2 [3]; 

function f(a,b) = .at.b; 

Each of these declarations introduces one or more segments and binds the 
identifiers mentioned (e.g., g, x, y, etc.) to the name of the first 
word of the associated segment. (The function declaration also initializes 
the segment named "f" to the appropriate machine code.) 

The segments introduced by these declarations contain one or more 
words, where the size may be specified (as in " local p[100]"), or defaulted 
to one (as in " global g;"). The identifiers introduced by a declaration 
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are lexically local to the block In which the declaration is made (that 
is, they obey the usual Algol scope rules) with one exception - namely, 
"global" identifiers are made available to other, separately compiled 
modules. Segments created by own , global , and function declarations are 
created only once and are preserved for the duration of the execution of 
a program. Segments created by local and register declarations are created 
at the time of block entry and are preserved only for the duration of the 
execution of that block. Register segments differ from local segments only 
in that they are allocated from the machine's array of 16 general purpose 
(fast) registers. Re-entry of a block before it is exitfed (by recursive 
function calls, for example) behaves as in Algol, that is, local and 
register segments are dynamically local to each incarnation of the block. 

There are two additional declarations whose effect is to bind identi- 
fiers to names, but which do not create segments; examples are: 

external s; 

bind y2 = y+2, pa = p+.a; 

^^ external declaration binds one or more identifiers to the names 
represented by the same identifier declared global in another, separately 
compiled module. The bind declaration binds one or more identifiers to 
the value of an expression at block entry time. At least potentially the 
value of this expression may not be calculable until run time - as in 
'pa = p+,a' above. 
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3.1.2 Data Structures (an introduction) 

Two principles were followed in the design of the data structure 
facility of Bliss: 

- the user must be able to specify the accessing algorithm 
for elements of a structure, 

- the representational specification and the specification 
of algorithms which operate on the information represented 
must be separated in such a way that either can be modified 
without affecting the other. 

The definition of a class of structures, that is, of an accessing 
algorithms to be associated with certain specific data structures, may be 
made by a declaration of somewhat the following form: 

structure <name> [<f ormal parameter list>] = ^ 

Particular names may then be associated with a structure class, that is 
with an accessing algorithm, by another declaration of somewhat the form: 

map <name> <name list> 

Consider the following example: 

begin 

structure ary2[i,j] = (.ary2+(.i-l)*10+(. j-1)) ; 
own x[100],y[100],2[100]; 
map ary2 x:y:z; 

• 

x[.a,.b] ♦- .y[.b,.a]; 
end ; ^ 
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In this example we Introduce a very simple structure, ary2, for two dimen- 
sional (10x10) arrays, declare three segments with names 'x', 'y', and 
'z' bound to them, and associate the structure class 'ary2' with these 
names. The syntactic forms "x[€j,,€2]" and "y[^>^]" are valid within 
this block and denote evaluation of the accessing algorithm defined by the 
ary2 - structure declaration (with an appropriate substitution of actual for 
formal parameters). 

Although they are not implemented in this way, for purposes of exposi- 
tion one may think of the structure declaration as defining a function with 
one more formal parameter than is explicitly mentioned. For example, the 
structure declaration in the previous example, 

structure ary2[i,j] = (.ary2+(.i-l)*10+(. j-1)) ; 

conceptually is identical to a function declaration 

function ary2(f0, fl,f 2) = (.fO+(.f l-l)*10+(. f2-l)) ; 
The expressions "x[.a,.b]" and "y['b,.a]" correspond to calls on this 
function - i.e., to "ary2 (x, .a, .b)" and "ary2(y, .b, .a)". 

Since, in a structure declaration, there is an implicit, un-named 
formal parameter, the name of the structure class itself is used to denote 
this "zero-th" parameter. This convention maintains the positional cor- 
respondence of actuals and formals. Thus, in the example above, ".ary2" 
denotes the value of the name of the particular segment being referenced, 
and 'x[.a,.b]' is equivalent to: 

(x+(.a-l)*10+(.b-l)) 
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The value of this expression is a pointer to the designated element of 

the segment named by x. 

In the following example the structure facility and bind declaration 

10 
have been used to encode a matrix product (z = S 3c.,y, .). In the 

inner block the names 'xr' and 'yc' are bound to pointers to the base of 

a specified row of x and column of y respectively. These identifiers 

are then associated with structure classes which allow one -dimensional 

access. 

begin 

structure ary2[i,j] = (.ary2+(.i-l)*10+.(. j -1) ) , 

row[i] = (.row+.i-l), 

col[j] = (.col+(.j-l)*10); 
own x[100],y[100],z[100]; /J 

map ary2 x:y:z; 

• 

Incr i from 1 t£ 10 do 

begin bind xr== x[.i,l], zr = z[.i,l]; map row xr:zr; 
incr j from 1 to 10 do 

begin 

register t; bind yc=y[l,.j]; map col yc; 

t ♦- 0; 

incr k from 1 to 10 do t *- . t+.xr[.k]*.yc[.k] ; 

zr[.j] *- .t; 
end ; 
end ; 

• 

end 
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3.1.3 The Actual Declaration Syntax 

The example declarations in the preceding two sub-sections are valid 
Bliss syntax; however, they do not reflect the complete power of the 
declarative facilities. The following sections (3.2 - 3.5) are definitive 
presentations of the actual syntax and semantics of these declarations. 
The actual declarations presented in the following sections differ from 
the examples given previously in that they admit greater interaction 
between the allocation declarations and structure declarations. 
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3.2 Memory Allocation 

There are five basic forms of allocation, declaration: 

allocation declaration -» allocatetype msidlist 
allocatetype -* GLOBAL | REGISTER | OWN | LOCAL] EXTERNAL 
msidlist -* msidelement jmsidelement , msidlist 
msidelement -♦ structure sizedchunks 
structure -♦ | structurename 

sizedchunks -» sizedchunk| sizedchunk: sizedchunks 
sizechunk -» idchunkj id chunk [elist] 
idchunk -♦ name] name: id chunk 

As with most other declarations, the allocation declarations 
introduce names whose scope is the block in which the declarations occur. 
REGISTER and LOCAL declarations cause allocation of storage at each block 
entry (including recursive and quasi-parallel ones), and corresponding 
de-allocation on block exit. Storage for OWN and GLOBAL declarations is 
made once (before execution begins) and remains allocated during the 
entire execution of the program. EXTERNAL declarations do not allocate 
storage, but cause a linkage to be established to storage declared with 
the same name in a GLOBAL declaration of another module. Space for 
allocation is taken from core for LOCAL, OWN, and GLOBAL declarations, 
and from the machine's high speed registers for REGISTER declarations. 

The initial contents of allocated memory is not defined and should 
not be presumed . 

Each msidelement defines a set of identifiers and simultaneously 
maps these identifiers onto a specified structure. (If the structure 
part is empty, the default structure 'vector' is assumed, see section 
3.5). Each sizedchunk allows, by interaction with the associated 
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structure of the msidelement, specification of the size of the segment 
to be allocated - and the values of the "undotted structure formals" 
to be used in accessing an instance of the structure (again, see 3.5), 



O 



o 



3.3 



O 



3.3 Map Declaration 

map declaration -♦ MAP msidlist 

The map declaration is syntactically and semantically similar to 
an allocation declaration except that no new storage or identifiers are 
introduced. The purpose of the map declaration is to permit re-definition 
of the structure and elist information associated with an identifier (or 
set of identifiers) for the scope of the block in which the map declaration 
occurs. 
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3.4 Bind Declarations 

bind declaration -♦ BIND equtvalencelist 

equivalencellst -» equivalence | equivalence, equivalencelist 

equivalence -♦ msidelement - e 

A bind declaration introduces a new ^et of names whose scope is the 
block in which the bind declaration occurs, and binds the value of these 
names to the value of the associated expressions at the time that the 
block is entered. Note that these expressions need not evaluate at 
compile time. 
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3.5 Structures 

structure declaration -* STRUCTURE name structureformaHist = structuresize e^ 
structureformallist -♦ | [naraelist] 
structuresize -♦ | [62] 

Structure declarations serve to define a class of data structures 
by defining an explicit "access algorithm", e. ,to be used in accessing 
elements of that structure. The class of structures introduced by such 
a declaration is given a name which may be used as the structure name in 
an allocation declaration or map declaration. 

The names in the structure formal list are formal parameter identifiers 
which are used in two distinct ways: 

1. "dotted" occurrences of the formal names positionally correlate 
with the values of elist elements at the site of a structure 
access. (Recall that a structure access is syntactically 

pi -* name [elist].) These are referred to as "access formals" 
and "access actuals" respectively. 

2. "undotted" occurrences of the formal names positionally correlate 
with the Values of the elist elements at the site of the declara- 
tion which associated the variable name with the structure 
class. These are referred to as "incarnation formals" and 
"incarnation actuals" respectively. 

In addition to the explicit formal names, the structure name, in "dotted" 

form, is used as an access formal to denote the name of the specific 

segment being accessed (that is, to denote the pointer to the base of 

the segment). J 
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If present, the structure size, i.e., [e], is used to calculate 
(from the incarnation actuals) the size of the segment to be allocated 
by an allocation declaration. After substitution of incarnation actuals, 
this expression must evaluate to a constant at compile time. 

The simple example of a two-dimensional array given in section 3.1.2 
might now be written: 

begin 

structure ary2[i,j] « [i*j](.ary2+(.i-l)*j+(. j-1)) ; 
own ary2 x:y:z[10,10]; 

x[.a,.b] ♦- .y[.b,.a]; 
end ; 

The default structure VECTOR, mentioned in section 3.2 is defined by 

structure vector [i] = [i] (.vector + .i); 

If defaulted, the size part of a structure declaration is defaulted 
to the product of the incarnation actuals. 
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function declaration -^FUNCTION name (namelist) = e | 

FUNCTION name = e | 
ROUTINE name (namelist) = e | 
ROUTINE name = e 

The FUNCTION and ROUTINE declarations define the name to be that of a poten- 
tially recursive and re-entrant function whose value is the expression e. 
The syntax of a normal subroutine -like function call is 

pi ->p1 (elist) I pi ( ) 
elist -> e I elist, e 

where pi is a primary expression. Clearly, pi must evaluate to a name which 
has been declared as a FUNCTION or ROUTINE either at compile time or at run 
time. The names in the namelist of the declaration define (lexically local) 
the names of formal parameters whose actual values on each incarnation are deter- 
mined by the elist at the call site. All parameters are implicitly Algol 
"call-by-value"; but notice that call-by-reference is achieved by simply pre- 
senting pointer values at the call site. Parentheses are required at the call 
site even for a ROUTINE or a FUNCTION with no formal parameters since the name 
on its own is simply a pointer to the function or routine. Extra actual para- 
meters above the number mentioned in the namelist of the function (or routine) 
declaration are always allowed; however, too few actual parameters can cause 
erroneous results at run time.' A ROUTINE differs from a FUNCTION in having an 
abbreviated and hence faster prolog. Restriction: a routine may not refer 
directly to local variables declared outside it, nor may it call a FUNCTION. /->v 

Note: If extra parameters are presented, and say, n are expected, then the 
rightmost n actual will correspond to the formal parameters. See section IV 
for details of the access mechanism. 
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function declaration -» GLOBAL ROUTINE name (naraelist) = e | 

GLOBAL ROUTINE name = e 

A ROUTINE name is like an OWN name in that its scope is limited to the block 
in which it is declared and its value is already initialized at block entry. 
The prefix GLOBAL changes the scope of the ROUTINE to that of the outer 
block of the program enveloping all the modules. Note that this inhibits 
a GLOBAL ROUTINE from access to REGISTER names declared outside it. This is 
in addition to the other limitations of ROUTINES cited on the previous page. 

Functions and routines may also be activated as co-routines and/or 
asynchronous processes, and indeed, the body of a single function may be 
used in .any or all of these modes simultaneously. (See 2,3.6.) 

function declaration ■-* FORWARD nameparlist 

nameparlist -» namepar | nameparlist, namepar 
namepar -» name (e) 

>v 
forward's tell the compiler how many parameters, given by e , are ex- 
pected by an undeclared function (or routine) name which will be declared 
later in the current block . The compiler permits the number of actual 
parameters in a function (or routine) call to be greater than or equal to 
the number of formals declared. 



Clearly e must evaluate to a constant at compile time. 
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3.7 Simple Macros 

A limited macro facility is provided to improve the usability of the 
language. This facility provides simple replacement of a macro ke3Word 
(and arguments) by a suitably defined string (with appropriate actual string 
substitution for the formal parameters). Nested macro calls are permitted. 
Recursive macro calls and nested macro definitions are not permitted. 

macrodeclaration -♦ MACRO macdefinitionlist 
macdefinitionlist -» macdefinition | 

macdefinitionlist, macdefinition 
macdefinition -^ name- (namelist) = stringwithout$ $ | 
namep = stringwithout$ $ 

The stringwithout$ is scanned for occurrences of atoms that match elements 
of the namelist (if any). The first $ terminates the macdefinition without 
exception. 

macrocall -♦ name^ (balancedstringlist) | 

name« 
balancedstringlist -» balancedstring | 

balancedstringlist, balancedstring 

A balancedstring is any string for which the number of right brackets 
("(", "["> or "<") in the string equals or exceeds the number of corres- 
ponding left brackets. This includes the null string. A balancedstring 
is' associated with the formal parameter in the corresponding ordinal 
position in the macdefinition. 
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Note that 

1, "Extra" balancedstrings will be simply ignored, but parsed 
as described above. 

2. Null balancedstrings are accepted, 

3, The macrocall may present fewer balancedstrings than the 
macrodefinition, in which case the null string will be used for 
the "missing" arguments. 

4. A macrocall must have a balancedstringlist if the macrodefinition 
had a namelist. 

The expanded string from a macro replaces the macrocall in the program 
prior to lexical processing and scanning resumes at the head of this string. 
Hence macrocalls may be nested. Indeed, parts of a "nested" call may come 
from the actual parameter (s) of the containing macro, from the body of the 
containing macro or even from the text following the containing macro. 

As with other declarations, macros have a scope given by the block 
in which they are defined - with this exception: Any macro being expanded 
at the end of a block will, in effect, be purged but its expansion will run 
to completion. This might occur, for example, if a macro contained an END as in: 

BEGIN 

MACRO QQSV « END B ♦- "TQ" $; 
QQSV 

END 

This may lead to ananolous behavior depending on the specific program. 
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Macros may be used to provide names to bit fields so as to improve 
readability. 



MACRO EXPONENT = 27,8 $; 

MACRO MANTISSA = 0,27 $; 

MACRO SIGN = 35,1 $; 

LOCAL X; 

X <SIGN> ^ 0; X <EXPONENT> «- 27; X <MANTISSA> <- .1; 



Macros may be used to extend the syntax in a limited way. 



MACRO NEC = GTR $; 

MACRO UNLESS (X) = IF NOT(X) $; 



Macros may be used to effect in-line coding of a function. 



MACRO ABS(X) = BEGIN REGISTER TEMP; 

IF NEG(TEMP <- X) THEN -.TEMP ELSE .TEMP END $; 
\ HERE THE ACTUAL PARAMETER SUBSTITUTED FOR X MAY NOT INCLUDE THE 
'. NAME TEMP. 



O 



o 



o 



II-1.1 



II. SPECIAL LANGUAGE FEATURES 

The previous chapter describes the basic features of the BLISS 
language. In this chapter we describe additional features which are 
highly machine and implementation dependent, 

1.1 Special Functions 

A number of features have been added to the basic BLISS language which 
allow greater access to the PDP-10 hardware features. These features have 
the syntactic form of function calls and are thus referred to as "special 
functions". Code for special functions is always generated in line. 
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1 .2 Character Manipulation Functions 

Nine functions have been specified to facilitate character manipula- 
tion operations. They ar6: 

scann (ap) copynn (ap- , ap«) 

scani (ap) copyni (ap-, ap2) 

replacen (ap, €) copyin (ap-, ap^) 

replacei (ap, €) copyii (ap- , ap^) 

incp (ap) 

For each of these € is an arbitrary expression, and ap is an expression 

whose \ralue is a pointer to a pointer. The second of these pointers is assumed 

to point to a character in a string. 

scann (ap) is a function whose value is the character from the 
string. 

scani (ap) is like scann except that, as a side effect, the 

string pointer is set to point at the next character 
of the string before the character is scanned. 

replacen (ap, €) is a function whose value is € and which, as a side 
effect, replaces the string character by €. 

replacei (ap, 6) is similar to replacen except that the string pointer 
is set to point at the next character of the string 
before the value of € is stored. 



copynn (ap-, ap^)\ these functions are similar in that they each effect 
copyni (ap-, ^.p^) I a copy of one character frcxn a source string (pointed 
copyin (ap , ap^) f at by .ap-) to a destination string (pointed at by .ap2) 
copyii (ap , ap ) I and have as value the character copied. They differ 

in that copynn advances neither pointer, viiile copyni 
advances .ap„, copyin advances .ap- , and copyii advances 
both. In each case the pointer is advanced before the 
copy is effected. 

incp (ap) advances .ap to the next character 
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Suppose that a string (of 7 bit ASCII characters) is stored in memory 

beginning at location S. The string is terminated by a null (zero) 

character. The following skeletal code will transform it into a 6-bit 

string with blanks deleted: 

t>e fi i n , 

register p7, p6, c; 

p7 <- (s-1) <1, 7>; p6 <- (s-1) <io,6>; 

while (c <- scani (p7)) neg do 

if .c neg " " then replacei (p6, .c) ; 
• • • 
end; 
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1 -^ Machine Language /^ 

It is possible to insert PDP-10 machine language instructions into a 
Bliss program in the syntactic form of a special function 

op (^i* ^2' S' V 
where 

op is one of the PDP-10 machine language mnemonics (see table 
below) . 

6^ is an expression whose least significant 4 bits will become 
the accumulator (A) field of the compiled instruction. 
This expression must yield a value at compile time of a 
declared register name or a literal. 

6^ is an expression whose least significant 18 bits will 

become the address (Y) field of the compiled instruction. 

€o is an expression whose least significant 4 bits will become 
the index (X) field of the compiled instruction. 

€, is an expression whose least significant bit will become 

the indirect (I) bit of the compiled instruction. /-^ 

(A table of machine language instruction mnemonics follows. Defaults for ^i~€/ are 0.) 

The 'value* of these machine language instructions is uniformly taken 
to be the contents of the register specified in the accumulator (A) field 
of the instruction. (This makes little sense in a few cases, but was 
adopted for uniformity.) 

In order for the compiler to conserve space during compilation, the 
mnemonics for the machine language operators are not normally preloaded 
into the symbol table. Therefore, in order to use this feature of the 
language, it is necessary for the programmer to include one of the follow- 
ing special declarations 

declaration ->MACHOP mlist ] ALLMACHOP 

mlli9t •-» name = e | mlist , name = e 
in the head of a block which embraces occurrences of these special functions. 



O 
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(Note: The e's in an mlist must be the high order nine bits of the actual 
values of the machine operation and must evaluate at compile time.) Symbol 
table space for these names is released when the block in which the declara- 
tion occurs is exited. 

NOTE : The description of fields ^> ^> ^ needs some simplification in 
the case where €« is a name. The compiler attempts to produce a single 
instruction for the machine language expression whenever possible. For 
example, consider the expression M0VEMi(5,A) where A is a local variable. 
The compiler, noting that the index register has been defaulted to zero, 
produces a 22 bit address using the F register for the index register field 
of the instruction. 
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PDP-10 Instruction Mnemonic Table 



O 



MOV 



E 

e Negative 
e Magnitude 
e Swapped 



HalfwordiJ^I'Slo 



Riglil 
Left 



no eFtt'ct 
Ones 
Zeros 
Extend siun 



lo Ai' 

Iriiniediato to \c 
to Memory 
to Self 



BLock Transfer 
EXCHange AC and meinory 



use present pointerl ( LoaD Byte into AC 
Increment pointer ( \ DePosit Byte in memory 

Increment Byte Pointer 



PUSH dow 
POP up 



11 



and Jump 



SET to< 



Zeros 
Ones 

Ac 

Memory 

Complement of Ac 
Complement of Memory^ 



AND 

inclusive OR 

Inclusive OR 
exclusive OR 
EQui Valence 



with Complement of Ac 
with Complement of Memory 
Complements of Both 



-to 



(AC 

AC Immediate 

Memory 

Both 



SKIP if memory] 
JUMP if AC J 

Add One to 



II 



memory and Skip) ,_ 



Subtract One from ) \ ac and Jump j 

^ . (Immediate \ , , . r 

Compare Ac i . , ., > and skip if ac 

*^ Iwith Memory I ^ 



never 
Less 
Equal 

Less or Equal 
Always 
Greater 

Greater or Equal 
. Not equal 



{Positive 
N 



ADD 

SUBtract 
MULtiply 
Integci ML'Uiply 
Divide 
Integer DlVide 



r 



rand Round- 



Float ing AdD 
Floating SuBtract 
Floating MultiPly 
Floating DiVidc 

Floating SCale 

Double F'loating Negate 

Unnorraalized Floating Add 



Immediate 
to Meinojy 
to Both 

Long 

to Memory 

to Both 



Arithmetic SHift 
Logical SHift 
ROTate 



I Combined 



Q 



Jump-< 



to SubRoutine 
and Save Pc 
and Save Ac 
and Restore Ac 
if Find First One 
on Flag and CLear it 
on overflow (JFCL 10,) 
on CaRrY (JFCL 4,) 
on CaRrY 1 (JFCL 2,) 
on CaRrY (JFCL 6,) 
on Floating overflow (JFCL 1,) 
and ReSTore 

and ReSTore Flags (JRST 2,) 
^and ENable I'l channel (JRST 12,) 

HALT (JRST 4,) 

eXeCuTe 



DATAl 
BLocK) 



CONditions-T 



(In 
[Out 



. ci ■ r- ( a" masked bits Zero 
i-m and akip if < , . . .^ ^ 

' \ some masked bit One 



o 



Test AC ■ 



with Direct mask 
with Swapped mask 
Right with E 
Left with li 



No modification 
set masked bits to Zeros 
set masked bits to Ones 
Complement masked bits 



and skip 



never 

if all masked bits Equal 

if Not all masked bits equal 

Always 



Reproduced with permission of Digital Equipment 
Reference Handbook. 



Corporation from the PDP-10 
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1.4 Compilation Control 

The actions of the compiler with respect to a program may be 
controlled by specifications a) in the initial input string from a TTY, 
b) in the module head, c) by a special SWITCHES declaration. Not all 
actions can be controlled from each of these places, but many can. 
Some actions once specified have a permanent effect (such as whether to 
create a high segment or low segment program) while the effect of others 
can be modified (such as listing control). The table in section 1.4.4 
gives a list of various compiler actions and the associated switch and/ or 
source language constructs which modify those actions. This list is 
subject to change. 
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1.4.1 Command Syntax 

The general format of the initial command to Bliss is: 

objdev: file,ext,lstdev: file.ext ♦- sorcdev: file. ext,. .. ,sorcdev: file. ext 

The "objdev: file.ext" and/or "Istdev: file. ext" may be omitted with the 
implication that the corresponding file is not to be generated. The 
".ext" may be omitted on any of the file specifications and the following 
defaults assumed: 

object file: REL 
listing filet LST 
source file: BLI 

As with DEC CUSP's, switches of the form /x (x?=A,B,. . . ,Z) may be placed 
anywhere in a command string. 



o 



o 
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1.4.2 Module Head 

As explained in 1,1,1 the syntax for a module is 

module -♦ MODULE name (parameters) « e ELUDa4 

The 'parameters' field may contain various information which will affect 
the compiler's action with respect to the current program. The syntax 
of this field is 

parameters -» parameter | parameter, parameters 

The allowed forms of 'parameter' are given in tabular form in section 
II. 1.4.4 under the column headed "module head syntax". 
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1.4.3 SWITCHES Declaration 

declaration -♦ SWITCHES switch list 

switch list -♦ switch | switch, switch list 

The SWITCHES declaration allows the user to set various switches 
which control the compiler's actions. The effect of a SWITCHES declara- 
tion is limited to the scope of the block in which the declaration is 
made. The various allowed forms of 'switch' are given in tabular form 
in section II. 1.4.4 under the column headed "SWITCHES DECLARATION". 



O 
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1,4,4 Actions 



COMMAMD 
SWITCH 


MODULE HEAD 
SYNTAX 


•SWITCHES' 
DECLARATION 


ACTION 


/L 


LIST 


LIST 


Enable listing of the source text. 
This switch is assumed true initi- 
ally. 


/K 


NOLI ST 


NOLIST 


Disable listing of the source text. 


/N 


NOERS 


NOERS 


Do not print error messages on 
the TTY. 


/M 


ML 1ST 


MLIST 


Enable listing of the machine 
code generated. 


/H 


HIS EG 


"* 


Make this module a highsegment 
module. Initially modules are 
assumed to be two segments. 


/I 


INSPECT 


INSPECT 


When true this switch will cause 
a special word to be emitted 
immediately prior to each function 
or routine body. This word contains 
information to facilitate a SIMULA- 
like inspection mechanism (see 
IV. 1.4). The default initial value 
of this switch is false. 


- 


NOINSPECT 


NOINSPECT 


This sets the inspection switch 
false. 


/s 






Enable listing of compiler .statistic 
Information relevant to the imple- 
mentation will be printed at the end 
of compilation. 


/x 


SYNTAX 




Syntax check onlyl No code will 
be generated - this speeds the 
compilation process and is there- 
fore useful during the initial 
stages of program development. 




DREGS«e 




'e' specifies the number of 
'declared' -type registers to be 
used. Unless specified this value 
is defaulted to a small number 
(three at the time of this writing) . 



II-1.4.4a 



COMMAND 
SWITCH 



/O 






/C 



/R 



/v 



MODULE HEAD 
SYNTAX 



RESERVE (e^,...e ] 



OPTIMIZE 



NOOPTIMIZE 

EXPAND 
NOEXPAND 



SREG = e 
VREG « e 
BREG « e 
FREG =* e 



NORSAVE 
RSAVE 



• SWITCHES ' 
DECLARATION 



OPTIMIZE 



NOOPTIMIZE 

EXPAND 
NOEXPAND 



NORSAVE 
RSAVE 



LOSEG 



LOSEG 



ACTION 



Registers with absolute names 
e^,...,e are reserved (usually 
for inter -module communication) , 

Because of the possibility of 
computed addresses in Bliss 
programs, it is not possible 
for the compiler to determine 
whether optimization of sub- 
expressions is possible.across 
";"'s in a compound expression. 
Therefore the compiler operates 
in two modes - one in which it 
does optimize such common sub- 
expressions and one in which 
it does not. When the 'optimize' 
switch is true the compiler 
attempts to optimize across a 
";". the default mode is for 
the switch to be true. 



Sets the optimization switch 
(see above) to false . 

Give trace of macro expansions. 

Turn off trace of macro expansion. 
This is default initial state. 



N 



The user may use these to choose 
^specific registers to be used as 
/the S, V, B, and F, respectively. 



J 



Print a cross-reference to all 
identifiers at the end of compilation 
(assumes a listing is being printed) • 

The compiler normally generates code 
to save all declarable registers 
around an EXCHJ operation. This 
default may be overriden by a /r, 
or NORSAVE. RSAVE reverts to the 
default. 

Force entire compilation into the 
low segment. 



O 
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COMMAND 


MODULE HEAD 


' SWITCHES • 


ACTION 


SWITCH 


SYNTAX 


DECLARATION 


— 


STACK 


^ 


The syntax of the module 




(see text at 




head permits automatic al- 




right) 




location and initialization 
of the run-time stack. The 
syntax is 

STACK STACK(<literal size:^ 
S TACK=<exp 1 i c i t - s t aclc?, ,. 

where 

<explicit-stack>: :=<stype> 

<s-name-sz> 
<stype>: :=GLOBAL OWN EXTERNAL 
<s-name-sz>: : = (<IDXss-OPTN>) 
<ss-OPTIC>: :=/<litera]> 

The defaults are 

'STACK'= STACK=OWN(STACK,#1000) 
'STACK(lit)'= STACK-OWN(STACK,lit 
etc. 


/G 


- 


- 


All routine names are forced to 
be 'global'. 




ENTRIES -(nT,,,n ) 




An 'entry' block is created at 






the beginning of the ' .REL' file 








for the names n^,n_,,„.n , These 
names must subsequently he declared 








'global' in the module. This per- 








mits FUDGE2 to be used to create 








a library. 
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1.1 Registers 

The sixteen registers are divided into three main classes: 

1. Reserved registers ; 

These registers are declared in the module head. Their scope 
is the entire module and they may also be accessed from within any 
global routine. They are never saved, 

2. Bliss run-time registers : 

After the reserved registers have been allocated, the lowest 
four remaining addressies are assigned as the run-time registers. 
In particular, if there are no reserved registers, through 3 are 
assigned as the S, B, F, and V registers respectively. The names 
SREG, BREG, FREG, and VREG are available at the outermost blocks 
of the module and, as in the case of reserved registers, these names 
are accessible from within any global routine. 

3. Temporary registers : 

All the remaining registers fall into this class and are divided 
into two subclasses: 
a. savable ; 

These registers are used for declared registers, 
control registers in incr-decr loops, and when necessary 
for computing temporary values. Any of these registers 
which are used in the body of a function or routine are 
saved in the prolog and restored in the epilog. Of course Cj 
if F is not a global routine and F is within the scope of 
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IV. RUN TIME REPRESENTATION OF PROGRAMS 

I.O Introduction 

In order to make the fullest possible use of Bliss, it is important 
to understand the run-time environment in which Bliss programs run. The 
address space is occupied by various types of information: 

(1) program 

(2) constants 

(3) static size variable areas (globals and owns) 

(4) stacks 

Programs are 'pure' (they do not modify themselves) therefore program 
and cotistant areas are placed in contiguous, write-protected regions 
and may be shared (see the 'HIGSEG' switch declaration, section 11,1.4), 
Static variable storage and stack space are placed in readable/ writable 
memory. The key to understanding the run-time environment in the stack 
configuration and register allocation is illustrated in Figure IV. 1. 
Each process (co-routine) has its own stack configured as shown in IV. 1. 
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of register R, then R is not preserved. The user must 
declare the size of this block of registers in the module 
head, (DREGS =). These registers are allocated from the 
highest addresses, 
b. non-savable ; 

These are the registers used for calculating inter- 
mediate results. They are saved at the call site of a 
function or routine only if they contain a needed result 
and are never saved in the prolog or epilog. 

Comments ; 

a. If one wishes to load a collection of Bliss modules together, 
they must request precisely the same reserved registers and request the 
same number of savable temporaries. 

b. The two classes of temporary registers are managed quite differ- 
ently in that the savable registers obey a stack discipline (to minimize 
saving and restoring) and the non-savable are used in round -robin fashion 
(to lengthen the life of intermediate results). The present version 

of the compiler requires a minimum of 4 non-savable registers — i.e., the 
maximum value of DREGS « 8 - # of reserved regs . In general the compiler 
can produce better code if DREGS is kept to the minimum value which the 
lexical scope of declared registers and/or incr-decr loops allow. 



O 



O 
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1 . 2 The Stack and Functions 

The first 17- locations of each stack are reserved for state informa- 
tion (registers plus program counter) for a process when it is inactive. The 
use of these cells is explained more fully in 1.4. The configuration 
above these 17 state words depends upon the depth of nesting of function 
calls, but each such nested call involves a similar (not identical) use 
of the stack; Figure IV. 1 illustrates a typical stack configuration 
after several nested functional calls. At a time when one of these 
functions is executing 

(1) The S-register points to the highest assigned cell in the 
stack; the S-register is used to control the allocation 
of the stack area, 

(2) The F-register points to the 'local base of stack'; below 
the F-register are the parameters to the function and the 
return address. The stack cell actually pointed to by 

the F-register contains the previous value of the F-register 
at the time at which the current function was entered, 

(3) The calling sequence which is used to enter a function (or 
routine) is 



PUSH S,p^ 

PUSH S,p2 

• « o 

PUSH S,p 
"^n 

PUSHJ S,FCN 

SUB S,[nooooon] 



push 1st parameter onto the 
stack 

push 2nd parameter onto the 
stack 



push nth parameter onto the 
stack 

jump to the called function 
delete the parameters 



(4) Above the F-register are stored the "displays", D , ..D- 



'below' in the sense of decreasing address values. 
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One display is used for each lexical nesting of the decla- 
ration of the function which is currently executing. The 
value of the displays are the F-register values for the 
most recent recursive entries for the lexically embracing 
functions. The displays are needed and used to access 
variables global to the current functions but local ta 
embracing functions. Such access is prohibited in routines, 
and consequently no displays are saved on a routine entry. 

(5) Above the displays are saved any savable registers which 
are destroyed by the execution of the function body. 
These registers are restored before the function exits. 

(6) Any local variables in the function are stored on top of 

the saved registers. Space Is acquired/deleted for locals Q 

on block entry/exit by simply adding/ subtracting a constant 
to the S -register. Some of these locals are automatically 
generated by the canpiler. 

(7) An excessive number of declared registers, or the evaluation 
of an unbelievably complex expression may exhaust the avail- 
able registers, forcing the area above the locals to be used 
for storing partial results of an expression evaluation. 

(8) The V-register is used to return the value of the function 
or routine. 

Figure IV. 2 illustrates the code generated surrounding the body of a func- 
tion. The code surrounding a routine body is identical with the exception 

that the displays are never saved. In this illustration the S, B, F, and r^ 

V registers are shown occupying physical registers 0-3. In practice other 
registers may be chosen if these registers are reserved in the module head. 



nJ 
O 

a 
o 

4J 
O 
C 



u 

o 

d 
o 

•H 

+J 

c 
o 
o 

o 
cd 
+J 

CO 



r^ 



Figure IV. 1 
Stack Structure and Registers for a Process 

__ miimm 



Local Variables 



Register Save Area 




The stack con- ^ 
figuration shown j 
above is repeated^ 
for each nested 
call. 

A 20 
Register save 17 
area when process 
is Inactive 5 

— i 4 

3 
State info for 

inactive pro- 2 

cess 



± 




A 

Declared and 
working registers 



£ 



STACK 



FCN: 


PUSH 


S,F 




PUSH 


S,1(F) 




• • • 

PUSH 


S,f(F) 




HRRZ 


F,S 




SUB I 


F,f 




PUSH 


S,F 




PUSH 


S.R 



PUSH S,R, 



Figure IV. 2 
Function Prolog and Epilog 

save old F-register 
copy display zero 

• 

copy display f 
set up new F 
subtract no. displays 
new display created 
save register 

• 

save register 



BODY OF FUNCTION OR ROUTINE 



POP S,R 



; restore register 



POP 
SUB 
POP 
POPJ 



S,R ; restore register 



4- 



^ 



S,[(f+l)0OO00(f+l)] ; eliminate displays I <- 
S,F 



Not 

Generated 
— For 

Routines 



O 



o 



s, 



MOVEM 
ADD 



Figure IV. 3 
Block Entry and Exit 



BENTER: MOVEM Rp/(+1 (F) 



Rj,i+j(F) 
S ,[nOOOOOn] 



; save in-use working registers 

• • • 

; save in-use working registers 

; INCR S-register by no. locals in blk 



BEXIT: SUB 



S,[(n+j)00000(n+j)] 



DECR S-register by no, locals in blk 
(note: in-use reg/.s left in stack, 
re- loaded only when used) 



O 
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1,3 Access to Variables 

This section briefly indicates the mechanisms by which generated code 
accesses various types of variables (formals, owns and globals, locals, 
etc.) The exact addressing scheme used by the compiler in any particular 
case is highly dependent upon the context; however, the following material 
should aid in understanding the overall strategy, 

(a) OWN and GLOBAL variables are accessed directly, 

(b) Formal parameters of the current routine are accessed negatively 
with respect to the F -register. If the current routine has n 
formats, then the ith one is addressed by 

(-n + i - 2) (F) 

(c) Local variables of the current routine are accessed positively 
with respect to the F-register, To access the ith local cell, 
one uses 

(i + d + r + 1)(F) 
where d is the number of displays saved and r is the number of 
registers saved on function entry. 

(d) Formal parameters and local variables which are not declared in 
the currently executing function are accessed through the dis- 
play. The appropriate display is copied into one of the working 
registers then accessed by indexing through that register in a 
manner similar to that shown in (b) or (c) above. 

The first four characters of the name introduced in the module head 
is used to name various regions in the produced code. These names are 
declared "external" and therefore available in DDT. If 'XXXX' are the 
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first four characters of the module name, then 



O 



xxxx 

XXXX.F 

xxxx.o 

XXXX.G 

XXXX.. 
XXXX.P 



is the location of the first instruction in the main 
body of the module. 

is the location of the "literal" area which contains 
constants generated by the compiler, 

is the location of the "own" area in which is stored 
all variables declared 'own' in the module. 

is the location of the "global" area in which is stored 
all variables declared "global" in the module. 

is the module name recognized by DOT. 

is the first location of the "plit" area. 
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V. COMPILER IMPLEMENTATION 

This table contains a description of the implementation of the Bliss 
compiler. At every instant of time this section will necessarily be in- 
complete and possibly erroneous. It will be extended and corrected as 
time permits and the compiler changes. 

The initial contents of the section is a set of diagrams of the major 
tables in the compiler. 
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value 




^ 



VE 
bit 



LS 
bit' 



Jo If value in next field 
S 1 if index into LT in next field 
I ("big" literals only) 




if symbol 

1 if literal 



O 



LT 



:±. 



^ 



N value 



VlfL 



1 



literal 

table 

hashed 

and 

treated 

as 

circular 



O 



THE LITERAL TABLE 



o 



V,3 



TOPOFTABLE = Index of last cell assigned 

-FREEHEAD =. index of first element in freespacelist (FSL) 



^ — ^ENDOFSPACE « index of last element (total size in cells) 

^NDLNK (=0) rtop of table 

^— j-always assig ned o r on FSL \ r 







f-end of space 



routine BIELEASESPACE links areas into FSL: 



__._£w 



H 



V 



X. 



.'i___ 



J 1 1. 



unassigned and not on FSL 



FSL =s set of areas linked 
together such that 
0th cell contains size 
of area, 1st cell 
has link to next area, 
(End of chain has 
link.) 



( 



routine GETSPAGE assigns areas from FSL: 



asslg 




Yes (returns *yes' 
rarely; '' 

7 GARBAGE COLLECTION -->-< 



Run down FSL; for each 
free cell, mark corres- 
ponding bit in AVL 
...C^¥4.11jah I e. . 



, C/jvail/thlp ■spac'ip .list) : 



x6S 



space 
assigned 



FSL after GETSPAGE 
T 




Check for adjacent marked 
bits hot linked in as one 
area. 

Rebuild FSL, collapsing 
adjacent areas, -—-———— 



^ 



n? 



•t"Y\ ' 



=^ 



^11 



Portion of FSL after 
rebuilding* 







a.ss 'fktK^jk. 



FREE SPACE LIST 
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The entire program is « llr^ked list, and is itself linked' to global variable PROGRAM: 



PROGRAM ~ 



CODE 



(example) 
if ,a then 
•b else .c 



Header 




kih 



eader 



HDR 



HDR 



HDR 



if-then-else 



IX 



if-then-else 



1 



HDR 



HDR 



HDR 



HDR 



if-then-else 



CODE 



jclass (wtype of code for header) 
-)subclass (=number of cells total) 



■' )initially the same 

as header class field 



"Jindex (ie., which item among 
the subheaders) 



if-then-else 



if-then-else 



jL J-ttien-e lse 



After processing, the above is equivalent to: 



I-T-E 



Subheader 

class 

changed to: IF 



ITE 
} 




ITE 


^ 


,2 


r i 


/ 


V. 



ITE 
3 



ITE 



{ 



ITE 
5 




Header 



Subheaders 



THEN Label ELSE 
After more processing, the above may change to: 



7 



Label 




tjochCja-CK 



• • .and so on* 
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THE CODE TABLE 
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SCALE OF 7-BIT CHABACTER CODES 



I 



character 1 



DELIMITERS 



DELIMITER TABLE 
DT 



a 



N 



mz 



M^ 



^ 



<r 



I — I I I -I.I 




character 128 



code 
for 
one 
delimiter 



computation on code 

(need only 20 values, 
not 128— eliminate 
: "gaps") 



/^ \ index i 



nto DT 



The 20 entries in DT are contiguous. 



J 



DELIMITER TABLE 



RAW 


1 
1 


TEXT 


1 

1 




,1 




TYPEDOPE 



1. pointer 
I pointer 



. 







fo 



M 



N<^ ^ TYPETAB 



BT 



1 \ « 

' ' ' 



4 bits 



+ 




TYPE 



digits 0-7 

1 digits 8-9 

2 letters 

O II I 

4 

5 CR : 

6 

7 special 

delim. 

.,;:+-*/ etc 
10 



17 ignore 
class 



Y^ 



± 



LEXAN 

(lexical 
analyzer) 



of charact 



Index 



2r 



^^ 



< 



lexemes 



\ 



THE TYPE TABLE 



o 



o 
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G8APHHEAD — Everything with the same hash code Is linked together. 




I 



iMMllEwMbMtav^ 



>»•"- 



±^ 



l.___ 




^FUNNYBIT— Equals 1 if the parents of this 
node are invalid, otherwise. 



4m4 






-^^™ 



RKB IT --Normally 0; 1 to mark GT entries 
which are contained in valid 
registers. Used only for GT-purge. 

-^SULTF— Equals 1 if RESULTWORB contains 

a valid result of applying the code 
generation routines to this node and 
subnodes . 
-yOCCF- -Occurrence count, or the number of 

nM.<t% which point to this node. 
^AVGEF- -Equals 1 to save GT-entries across 
forks (such as if-then-else) . Entry 
with non-zero SAVGEF never purged. 
-^ZF--Number of two-word cells in the GT-entry, 

y^SUBNF— Subnode field, equal to number of 

operand lexemes (1 for unary operators, 
2 for binary, etc.) 



LINKF^ 



\ 



RESULTWOED 



OPERATOR LEXEME 



OPERANDI 



0PERAND2 



OPERANDS 



iiKwuimiHiiiiu iiii 




Link to 
next node 
with same 
hash code J 
the infor- 
mation in 
each node 
occurs only 
once in the 
whole list. 



THE GRAPH TABU 



OPERAND LEXEME 



i 


\ 


D 

T 


POSN 


SIZE 


D 
T 




L 
S 


VE 


LTE 




STE 


t0fHtr 


RTE 


LSSTE 1 










1 








1 


\ f 



short literal)j^f 


1 
i 




i ! 
' 1 

I ' 














1 

! 


long literal J [ 






. 1 

; 1 














1 

1 


name N 

contents of ^_ 
register ©R 






1 1 

> 1 

! ; 














1 


pointer N<P,S> 






1 1 ' ^ 


P(literal)-y 


^^-S( literal)-!^ | 

4~ - v' 


,N<P,S> 






' 1 1 ^ 






/ 


^ 


O 




!»| 


a. 






I'!" 











1 


1 





0, 


-©N 


1 





1 "0 

1 











1 


I 





01 


not @N ( 





1 


1 
1 |0 











' 


1 





0, 


not<S)(N+®R) 1 

1 

1 





1 

* 


i|o 

1 











1 


1 





n ' • 


^ 



R 





1 

1 f- 



1 <- 



f 



f- 



■^1 






13 13 
value in range -2 to 2 -1 



index to literal table 
index to symbol table — 



■> 



0000 000000000 

- index to symbol table -^ 

N -> 

N • > 

N • j 



— N — 

— N - 



< 

00 



NOTES: 



1, Neg and Not may not both be set, 
SrsO indicates P,S unset. 

The name of a declared register is a literal, 

2, A graph-table lexeme is considered a special form of 

operand lexeme and is distinguished by a left-half equal to -5^5^077777, 



OPERAND LEXEMES 



o 



o 



o 



V.9 



BUFF 



current line image in ASCII 



llnecnt 





b 


e 


B 


1 


n 




— 
1 


o 


c 


a 


1 




X 


— 

• 

> 


... 7 




ta.. 










— . 


U 






— 




-.- 




,) 



Values associated 
with BUFF are: 



(l)rBUFF, points to next character to be 
scanned 



1' 








line no, 
* 16 


char, 
no. 



(2)CHA.R, contains the character to be scanned 



(3)NCBUFF, used for printing error messages-- 
polnts to place In line where error 
was detected 



(4)V4LIDBUF = [° ^^ ^^^^ ^^""^ ^^^ ^^^"^ printed 

* \l if this line has not been printed 



The sequence is: 



READ a line 

PROCESS that line 

PRINT previous line (check VALIDBUF first) 

READ next line 

(repeat) 



As characters are read, ACCUM is being built: 
ACCUM 



^T^ 



PACCUM, points to last character pulled out of BUFF 
and put into ACCUM 



BUFF and ACCUM 



v.io 



The major purpose of the lexical analyzer ts to maintain the WINDCW; 

routine WRUND (read until next delimiter) keeps the WINDCW filled. 

Meam^lle, another window-like structure ren«nibers the M^BUFF for 

lexemes m the WINDOW, for use when errors are detected, 
WINDOW 



O 



SYM 

operand lexeme 
or empty 



DEL 

operator lexeme 
(never empty) 



FUTSYM 

operand lexeme 
or empty 




Y 



FUTDEI* 

operator lexeme 
(never empty) 



/ 



HEALFS 



ST Index of 

names In 

sym and/or futsym 



O 



/ 




\ 
\ 




/ 

1 


V 

• 




NSYM 


NDEL 


NFOTSYM 


NFUTDEL 



The above are values of NCBUFF for these atoms, 

For x<-,x+l ... the BUFF and WINDOW look like: 

NCBUFF 



L 



X 


«- 


• 


X 


+ 


1 


... 


SYM DEL 


FUTSYM FUTDEL 


X 


«- 


<empty> 


• 



THE WINDOW 



o 



GTP — 

GLOBAL mBLE POINTER 




for something 
declared GLOBAL 



NIXT 

ELEMENT 
IN 
GLOBAL 
TABLE 



THE GLOBAL TABLE 



V. 12 



HA.SHT (hash table for all symbols) 



O 



TABLE (the 


f 


symb 


ol 1 


table) 




r-l 










o 


O 








_ _. 


•9 


rQ 


ru 








^ 


R 


3 








/ " 


03 











"n_: 






7C 
^ 



OCCURRENCES OF 
A SYMBOL ARE 
LINKED IN THE 
REVERSE ORDER 
OF DECLARATION, 



ttr. r 
from 

HASHT 



entry, n (2 cells) 



own 



LINK 



Additional Informa- 
tion 



AJP 



7. 



(example) 

begin 

local AJP; 



begin 
-— own AJP ; 



•JLBLOCKLEVEL 



i 



^FCNLEVEL 
(function level) 



Jl 



>TYPE 
LINK 



local 



(end) 
LINK 



Add'l Info. 



AJP 



Symbol 



O 



end; 



end; 



O 



THE SYMBOL TABLE 



V.13 

For the codef 

structure vec[l] ■ (.vec+,l)<0,36>| 
local x; 
nap vec kj 

• 

x[5]4- 1; 

begin 

map newstr x; 

end; 
3c[3j«- 4; 



the STE would look like the following, until block 2 is entered: 

incarnation ^^E for 



STE for X 



actuals 



jf-^ 



On entering 

block 2, the 

above is put 

into map 

table, creating link-> 

mPTB 



^ 



MAPTB entry 




STE fttr X 



X 



fl 



incarnation 
actuals 



structure 



^'. 



vec 



STE for newstr 



newatr 



A unique map table exists for each block level; only "remapped" variables 
have entries in the table. 



Tin? MA T> TA ti.Y 1? 



Header cell 



FCNLIST 



i 



■ 




Subheader 



If this node is 
never used, "bottom" 
word filled with 7 'a, 



i 



ptr. to 

STE for 
function 

name 



h 



Each subheader points to 
rout ine/s true ture/funt ion 
body code« The code may 
disappear, but this list 
remains throughout. 



(If the node is 
used) bottom word ^— 
points to the 
most recent use 
of the function/ 
structure/routine, 
whose node is in 
turn lilted to the 
next most recent 
use, etc. 



THE FUNCTION LIST 



o 



o 



o 



POINTIR 



RELCX3F Indicates whether ADDR is CWN, GLOBAL, etc. 



irhfi — 5 







RELOGF 








POSN 


SIZE 


1 
I 
N 


INDEX 


ADDR 






D 














1 







tinused 



< 



POINTER TABLE 



A« J- 



o 

APPENDIX A; SYNTAX 

module -* MODULE name (parameters) e ELUDOM 

block -* BEGIN blockbody END | (blockbody) 

compoundexpression -♦ BEGIN expressionsequence END | (express lonsequence) 

blockbody -♦ declarations; express lonsequence 

declarations -♦ declaration | declaration; declarations 

express ionsequence -♦ | e | e; express lonsequence 

comment -♦ | 1 res tof line endoflinesymbol | ^ st^ingwithnopercent ^ 

literal -* niMiber | quotedstrlng 

number -* decimal | octal | floating 

decimal -* digit | decimal digit 

o 

octal -♦ # oit I octal oit 

floating -♦ decimal, decimal | decimal. decimal exponent 

exponent -♦ E decimal | E + decimal | E - decimal 

digit -• 0| l|2 --- I 9 

oit -»,0|l|2 --- |7 

quotedstrlng -+ leftadjustedstring | rightadjustedstring 

leftadjustedstrlng ■-» 'string' 

rightadjustedstring -♦ "string" 

e -* simpleexpression, | controlexpression 

simpleexpression -* pll ♦- e | pll 

pll -» plO I pll XOR plO I pll EQV plO 

plO -» p9 I plO OR p9 

p9 -» p8 I p9 AND p8 r~N 

p8 -♦ p7 I NOT p7 

p7 -♦ p6 I p6 relation p6 



At *^ 



p6 -» p5 I - p5 I p6 + p5 I p6 - p5 

p5 -» p4 I p5 * p4 I p5 / p4 I p5 MOD p4 

p4 -♦ p3 I p4 t p3 

p3 -* p2 I .p3 I %3 Kp3 

p2 -♦ pi I pi <pointerparameters> 

pl -* literal | 

name | 

name [elist] = 

pl (elist) I 

PlO I 

block I 
compoundexpression 
relation -♦ EQL | NEQ | LSS | LEQ | GTR | GEQ 
pointerparameters -♦ position, size modification 
modification -♦ | , index | , index, indirect 
position -^ I e 
size -♦ I e 
index -* | e 
indirect -» | e 
controlexpression -* conditionalexpression | loopexpression | 

choiceexpression | escapeexpression | coroutineexpression 
conditionalexpression -* IF e^^ THEN o.^ | IF e, THEN e^ ELSE e« 
loopexpression - WHILE e^ DO ^^ 
loopexpression - UNTIL e^ DO e^ 
loopexpression - DO ^^ WHILE e^ 
loopexpression -* DO e« UNTIL e. 



A.3 

O 

loopexpresslon ^ INCR name FROM e^ TO 62 BY e^ ^0 % 
loopexpresston -» DECK name FROM e, TO et„ BY e^ DO e, 
escapeexpression -♦ environment level escapevalue | RETURN escapevalue 
environment -* EXIT | EXITBLOCK | EXITCQMPOUND | EXITLOOP | EXITCONDITIONAL 

EXITCASE I EXITSET | EXITSELECT 
level -* I [e] 
escapevalue - | e 

choiceexpression -* CASE elist OF SET expresslonset TES 
ellst -* e I e, elist 

expresslonset -» |e|; expresslonset | e ; expresslonset 
choiceexpression -* SELECT ellst OF NSET nexpresslonset TESN 

nexpressionset -♦ | ne | ne; nexpresslonset f) 

ne -♦ e : e 
coroutineexpression -* CREATE e. (ellst) AT e^ LENGTH e_ THEN e, | 

EXCHJ (e,, e ) 
declaration -♦ functlondeclaration| structuredeclarationj 

binddeclarationjtaacrodeclaration| 

allocationdeclaration|mapdeclaration 
allocationdeclaratlon -♦ allocatetype msldlist 
allocatetype -♦ GLOBAL | REGIS TER| 0WN| L0CAL| EXTERNAL 
msldlist -♦ msidelement |msidelement, msldlist 
msidelement -♦ structure slzedchunks 
structure -♦ | structurename 

slzedchunks -* sizedchunk] sizedchunk: slzedchunks 

s ize chunk -♦ idchunk | idchunk [elist] V_y 

idchunk -* name I name : idchunk 



A.4 



mapdeclaration -» MAP rasidlist 

binddeclaration -► BIND equivalencelist 

equivalence! 1st -♦ equivalence | equivalence, equivalencelist 

equivalence -* msidelement » e 

structuredeclaration -» STRUCTURE name structureformallist « structuresize 
structureformallist -♦ | [naraelist] 
structuresize -* \ [e] 

function declaration -* FUNCTION name (naraelist) = e | 

FUNCTION name = e 
ROUTINE name(namelist) « e | 
ROUTINE name = e 
pi -* pi (elist) I pi ( ) 
elist -♦ e I elist, e 
functiondeclaration -♦ GLOBAL ROUTINE name (namelist) = e | 

GLOBAL ROUTINE name = e 
functiondeclaration -* EXTERNAL nameparlist | 

FORWARD nameparlist 
nameparlist -» namepar | nameparlist, namepar 
namepar -♦ name (e) 
macrodeclaration -♦ MACRO definitionlist 

definitionlist -♦ definition | definitionlist, definition 
definition -* name (namelist) = stringwithout$ $ | 
name = stringwithout$ $ 
macrocall -♦ name (balanced stringlist) | name 

balancedstringlist -♦ balancedstring | balancedstringlist, balancedstring 
declaration -♦ MACHOP mlist | ALLMACHOP 
mlist -* name =* e | mlist, name = e 



n» J 



o 

module -♦ MCa)lH.l name (parameters) « e ELUDOM 
parameters -* parameter | parameter, parameters 
declaration -♦ SWITCHES switchlist 
swltchllst -♦ switch | switch, switchlist 
name -* letter | name letter | name digit 
letter -♦ A|b| , ., |z|a|b| . .. |z 



O 






B.l 



APPENDIX B: INPUT-OUTPUT CODES "^ 



The table beginning on the next page lists the complete teletype code. The 
lower case character set (codes 140-176) is not available on the Model 35, 
but giving one of these codes causes the teletype to prim the corresponding 
upper case character. Other differences between the 35 and 37 are men- 
tioned in the table. The definitions of the control eodes are those given by 
ASCII. Most control codes, however, have no effect on the console teletype, 
and the definitions bear no necessary relation to the use of the codes in con- 
junction with the PDF- 10 software. 

The line printer has the same codes and characters as the teletype. The 
64-charactcr printer has the figure and upper case sets, codes 040-137 
(again, giving a lower case code prints the upper case character). The **96"- 
character printer has these plus the lower case set, codes 040-176. The 
latter printer actually has only ninety-five characters unless a special charac- 
ter is "hidden" under the delete code. 177. A hidden character is printed by 
sending its code prefixed by the delete code. Hence a character hidden under 
r^'] DEL is printed by sending the printer two 1 77s in a row. 

Besides printing characters, the line printer responds to ten control charac- 
ters, HT. CR, LF, VT, FF, DLE and DCi -4. The 1 28-character printer uses 
the entire set of 7-bit codes for printable characters, with characters hidden 
under the ten control characters that affect the printer and also under null 
and delete. In all cases, prefixing DEL causes the hidden-character to be 
printed. The extra thirty-three characters that complete the set are ordered 
special for each installation. 

The first page of the table of card codes \pages ] lists the column 

punch required to represent any character in the two DEC codes. The octal 
codes listed are those used by the PDP-10 software. In other words, when 
reading cards, the Monitor translates the column punch into the octal code 
shown; when punching cards, it produces the listed column punch when 
given the corresponding code. The remaining pages of the table show the 
relationship between the DEC card codes and several IBM card punches. 
Each of the column punches is produced by a single key on any punch lor 
which a character is listed, the character being that which is printed at the 
top of the card. 



C *Thls appendix reproduced with the. permission of Digital Equipment 

Corporation from the PDP-10 Reference Handbook. 
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INI'l) I ol' I I'f I I (M'l 



Tlil.l I^ PI (ODI 



O 



Even 


7-Bit 




Parity 


Octal 




Bit' 


Code 


Character 





000 


NllL 


1 


001 


son 


1 


002 


srx 





00.^ 


FIX 


1 


004 


hOT 





005 


INQ 



006 ACK 

1 007 BEL 
1 010 BS 



on 

012 

013 
014 
015 
016 
017 
020 
021 
022 

023 
024 

025 
026 
027 
030 
031 
032 
033 

034 
035 



HT 
LI 

VT 
\V 
( R 
SO 
SI 

DLH 
DCl 
DC 2 

DC 3 
DC4 

NAK 

SYN 

hTB 

CAN 

HM 

SUB 

hSC 

FS 

C.S 



Remarks 

Null, tape feed, Repeats mi Model 37. ("(miUdI sliilt P on Model 35. 

Start of heading; also SOM, start ol message. Control A. 

Start of text; aJsc) FOA. enil o\' address. Control B. 

End of text: also hOM. end of message. (. ontrol C. 

End of transmissi(>n (IiND); shuts off IWX machines. Control D, 

Enquiry (ENQRY); also WRU. "Who are you?'* Triggers identification 
("Here is . , . ") at remote station if so equipped. Control F. 

Acknowledge; also RV. '"Are yi)U . '" Control f . 

Rings the bell. C'ontrol (1. 

Backspace; also IT-C), foriiuit effector. Backspaces some machines. 
Repeats on Model 37. Control 11 on Model 35. 

Horizontal tab. Control 1 on Model 35 

Line feed or line space (NI W L.INl K advances paper to next line. Repeats 
on Model 37. Duplicated by control J on, Model ^5. 

Vertical tab^VIAB). (ontrol K on Model 35. 

Form feed to to[> ot next page (P.AC.I ). Control L. 

Carriage return to heginning of line. ( t)ntrol M on Model 35. 

Shift out; changes ribbt.»n color to red Control N. 

Shift in; changes ribboji color to black. C ontrol O, 

Data link escape. Control P (DCO). 

Device control I . turns transmitter < reader) on. Control < X ON). 

Device control 2. turns punch or auxiliary on. Control R (TAPE, 
AUX ON). 

Device control 3. turns transmitter (reader) off. Control S (X OFF). 

Device control 4. turns pimch or auxiliary off. Control T ( TAPE, 

AUX OFF). 

Negative acknowledge; also 1 RR. error. Control U. 

Synchronous idle (SYNC), (ontrol V. 

End of transmission block; also LEM. logical end of medium. Control W. 

Cancel (CAN(L). (ontrol \. 

End of medium. Cnntrt)l Y. 

Substitute. Control Z. 

Escape, prefix. This code is generated by control shift K on Model 35. 

but the Monitor tran.slates it io 175. 

I'ile separator. Control shift L on Model 35. 
(jroup separutoi. Control -lull M <mi Model .'5. 



O 



o 



Even 
Parity 


7-Bit 
Octal 




Bit 


Code 


Character 





036 


RS 


1 


037 


US 


1 


040 


SP 





041 


1 





042 


tt 


I 


043 


# 




1 


044 
045 


$ 


1 


046 


& 





047 


t 





050 


.( 


1 


051 


) 


1 


052 


« 





053 


+ 


1 


054 


J 





0-55 


- 





056 


. 


1 


057 


/ 





060 





1 


061 


1 


I 


062 


2 





063 


3 


1 


064 


4 





065 


5 





066 


6 


1 


067 


7 


1 


070 


8 





071 


9 





072 




1 


073 







074 


< 


I 


075 


= 


1 


076 


> 





077 





1 


100 


(^: 





101 


A 





102 


B 



B.3 

in rrsri < "Oi 



Ketnarks 

Record separutor. ( ontiol shift N on Model 35. 
Unit separator. Conlrol shili () on Model .V^. 
Space. 



Accent acute or apostrophe. 



Repeats on Model 37. 



Repeals on Model 37. 
Repeats on Model 37. 



Repeats on Model 37. 



B4 



B.4 

INIT I (illl'll • : .\i\ 



Even 

Parity 

Bit 


7-Bit 
Octal 

Code 


Character 


1 


103 


(' 





104 


1) 


1 


105 


E 


1 


106 


1 





107 


G 




1 


no 
11 1 


H 
1 


1 


112 


J 





113 


K 


I 


114 


L 





115 


M 





116 


N 


1 


117 


O 





120 


P 


I 


121 





1 


122 


R 





123 


S 


1 


124 


1 





125 


U 





126 


V 


1 


127 


W 


] 


130 


X 





131 


Y 





132 


Z 


! 


133 


I 





134 


\ 


1 


135 


J 


1 


136 


t 





137 


♦- 


d 


140 




1 


141 


a 


1 


142 


b 





143 


c 


1 


144 


d 





145 


e 





146 


f 


1 


147 


g 



o 



Hcii>:irk> 



o 



Repcjits on Model 37. 



Shift K on Model 35. 
Shift Lon Model 35. 
Shift M on Model 35. 

Repeats on Model 37. 
Accent grave. 



O 



B.5 



III I I HI Ul 



Even 


7-Bil 




Parity 


Octal 




Uit 


Ccjcle 


Character 


I 


150 


h 





151 


i 





152 


J 


1 


153 


k 





154 


I 


! 


155 


m 


1 


156 


n 





157 


o 


1 


160 


P 





161 


q 





162 


r 


1 


163 


s 





164 


t 


1 


165 


u 


1 


166 


V 





167 


w 





170 


X 


I 


171 


y 


1 


172 


z 




1 


173 
174 


\ 

1 





175 


' 





176 


~ 



Remark' 



Repeats on MihIcI 37. 






DEL 



This code generated by ALT MODE on Model 35. 

This code generated by ESC key (if present) on Model 35. but the 

Monitor translates it to 175. 

Delete, rub out. Repeats on Model 37. 



REPT 

PAPER ADVANCE 
LOCAL RETURN 
LOCLF 
LOC CR 

INTERRUPT, BRI.AK 
PROC EED, BRK RLS 
HERE IS 



Keys That Generate No Codes 

Model 35 only: causes any other key that is struck to repeat continuously 

until REPT is released. 

Model 37 local line feed. 

Model 37 local carriage return. 

Model 35 local line feed. 

Model 35 local carriage return. 

Opens the line (machine sends a continuous string of null characters). 

Break release. (not applicable) 

Transmits predetermined 21 -character message. 



MAY r't>H 



B.6 



IMi. I (U' I I'll I 



( ARI) (oni s 





PDP~10 








PDP 10 






Character 


ASCII 


DEC 029 


1)1 ( 026 


( h.ii.uMcr 


AS( 11 


uric 029 


DLC" 026 


Space 


041) 


.\oHV 


.\V>//(' 




1 00 


8 4 


8 4 


1 


041 


11 H 2 


12 H 7 


A 


loi 


i: 1 


12 1 


" 


042 


H 1 


8 5 


W 


lo: 


] T T 


1 T T 


# 


043 


8 3 


8 6 


C 


103 


12 3 


12 3 


S 


044 


118 3 


1! 8 3 


1) 


104 


12 4 


12 4 


f / 


045 


8 4 


8 7 


1 


105 


12 5 


12 5 


& 


046 


12 


118 7 


1- 


106 


12 (. 


, 12 6 


' 


047 


8 5 


8 6 


c; 


10.^ 


12 7 


12 7 


( 


050 


12 8 5 


8 4 A 


H 


1 10 


12 8 


12 8 


) 


051 


118 5 


12 8 4 A 


1 


1 11 


12 9 


12 9 


♦ 


052 


1184 


118 4 


J 


112 


11 1 


11 1 


+ 


053 


12 8 6 


12 


K 


113 


11 2 


112 


. 


054 


08 3 


8 3 


L 


114 


11 3 


11 3 


- 


055 


11 


11 


M 


115 


11 4 


11 4 




056 


12 8 3 


12 8 3 


K 


■11(1 


1 ! 5 


1 1 5 


/ 


057 


1 


1 


() 


117 


11 6 


n 6 





060 








P 


120 


11 7 


n 7 


1 


061 


1 


1 





121 


11 8 


11 8 


1 


062 


2 


T 


K 


122 


11 9 


n 9 


3 


063 


3 


3 


S 


123 


2 


2 


4 


064 


4 


4 


T 


124 


3 


3 


5 


065 


5 


5 


U 


125 


4 


04 


6 


066 


6 


6 


V 


126 


5 


5 


7 


067 


7 


7 


w 


127 


6 


6 


8 


070 


8 


8 


X 


130 


7 


7 


9 


071 


9 


9 


Y 


131 


08 


08 




072 


8 2 


1 1 8 2 f;r 1 1 


z 


132 


9 


9 


■ 


073 


118 6 


8 2 


I 


133 


12 8 2 


II 8 5 


< 


074 


12 84 


12 8 6 


\ 


134 


118 7 


8 7 


= 


075 


8 6 


8 3 


1 


135 


08 2 


12 8 5 


> 


076 


08 6 


118 6 


t 


136 


12 8 7 


8 5 


•> 


077 


8 7 


1 2 8 2 fir 1 2 


*r'^ 


137 


8 5 


8 2 


Binary 


7 9 














Mode Switch 


12 


246 8 












End of File 


12 11 


I 













The octal codes given above are those generated l^y the Monitor iron! the column punches. The card 
reader interface actually supplies a dir&ct binary equivalent ol the column punch, as listed in the following 
two pages. 



O 



O 



o 



MAY 1968 



B.7 



Punch 


Mono 




1 


1 


^ 


4 


5 


6 


7 


8 


9 


12 1 


12 2 


12 3 


12 4 


12 5 


12 6 


12 7 


12 8 


Column 


Punch 


12 


11 


12 


11 


8 2 


8 3 


8 4 


8 5 


8 6 


8 7 


12 8 2 


12 8 3 


J2 8 4 


12 8 5 


12 8 6 



Character 



& 



# 



Octal 



Space 


0000 





1000 


1 


0400 


■■) 


0200 


3 


.0100 


4 


0040 


5 


0020 


6 


0010 


7 


0004 


8 


0002 


9 


0001 


A 


4400 


B 


4200 


C 


4100 


D 


4040 


E 


4020 


F 


4010 


G 


4004 


H 


4002 


026 Data 


026 


Processing 


Fortran 



+ 



t AUI) 1 ( HH N 


(. olutnn 








Punch 


Character 


Octal 




1 2/' 


1 


4001 




II 1 


J 


2400 




11 2 


K 


2200 




113 


1. 


2 1 00 




1 1 4 


M 


2040 




11 5 


N 


2020 




116 


O 


2010 




11 7 


P 


2004 




11 8 





2002 




11 9 


R 


2001 




1 


/ 


1400 




2 


S 


1200 




3 


T 


1100 




04 


U 


1040 




5 


V 


1020 




6 


W 


1010 




7 


X 


1004 




08 


Y 


1002 




9 


Z 


1001 



029 



DEC 026 



DEC 029 

& 



p- 


=r 


# 


<" 


T 


C^ 



) 

I 

< 



+ 



Octal 

4000 
2000 
5000 
3000 
0202 
0102 
0042 
0022 
0012 
0006 
4202 
4102 
4042 
4022 
4012 



B.8 



3lun\n 


026 Data 


026 


i^lnch 


Processing 


Fortran 


12 8 7 






118 2 






118 3 


S 


$ 


118 4 


« 


* 


118 5 






118 6 






118 7 






08 2 






08 3 


, 


t 


08 4 


% 


( 


08 5 






08 6 






8 7 






12 11 1 






12 2 4 6 8 






7 9 







!N('i' i (juii'i.T t<ti>r:s 



02^) 



> 



l>Et 026 



DEC 029 



s 


$ 


S 


■k 


♦ 


« 


) 

» 


> 


) 


1 


& 


\ 


Sec note 




] 



# > 

':< 1 

End of File End of File 

Mode Switch Mode Switch 

Binary Binary 



Octal 

4006 
2202 
2102 
2042 
2022 
2012 
2006 
1202 
1102 
1042 
1022 
1012 
1006 
7400 

xxOS 



Note: There is a single key for the 8 2 punch on the 029 but printing is suppressed. 

The Monitor translates the octal code for the 1 2 punch in DEC 026 to 4202 (which corresponds to a , 
12 8 2 punch), and the code for 1 1 to 2202 ( 1 1 8 2). 



O 






O 
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APPENDIX C; WORD FCtimTS 



<P,S> refers to a field S bits wide and P bits up from the right hand 
end of the word, thus: 



:36 - S - P>- 



X 



T, 



'I 



referenced partial word 



The format of a pointer is 



P = <30,6> 
S = <24,6> 
I = <22,1> 
X = <18,4> 
Y = <0,18> 



Position 

Size 

Indirect address 

Index 



The format of an (non l/o) instruction is 

F = <27,9> 
A = <23,4> 
I,X,Y as above 



Function code 
Accumulator 



The format of an integer number is 

SIGN = <35,1> 
MAGNITUDE = <0,35> 

The format of a floating point number is 

SIGN = <35,1> 

EXPONENT = <27,8> 
MANTISSA = <0,27> 



D.l 



APPENDIX D: BLISS ERROR MESSAGES 



O 



NUMBER 



MESSAGE 





1 

2 

3 

4 

5 

6 

7 

10 

II 

12 

13 

14 

15 

16 

20 

21 

23 

26 

30 
31 
32 
33 
34 

36 
37 



undeclared identifier 

error in simple expression 

not the correct matching close bracket 

expressions must be separated by a delimiter 

an operator must be followed by a simple expression 

a relational expression must not be followed by a relational operator 

a unary (binary) operator must (not) be preceded by a delimiter 

a control expression must not be used as a subexpression 

left part of an assignment is incorrect 

too many «-'s (current implementation allows 8) 

righthand side of an assignment is incorrect 

an actual parameter expression should not be empty 

a simple expression should be followed by a delimiter 

a subscript expression should not be empty 

too many subscripts (current implementation allows 8) 

OF must be followed by SET in CASE stmt 

incorrect escape expression 

missing control variable in INCR or DECR 

the constituent expressions of a complex expression should not be empty 

declarations are only allowed in a block head 



current close br does not match marked open bracket (paired with err 31) 
not the correct close bracket 



'v_y 



illegal control variable name tn INCR or DECR 

empty condition in WHILE-DO, UNTIL-DD, DO-WHILE, or DO-UNTIL 



O 



Warnine messaee, not fatal 



D.2 



NUMBER 



MESSAGE 



40 
41 
42 



•}'<• 



43 
44 

45 
46 
47 
50 



51 
52 
53 
54 
55 
56 
57 
60 



62 
63 
64 
65 
66 
67 
70 
71 
72 
73 



illegal up-level addressing 

too many parameters in a pointer expression 

too many close brackets, or not enough opens (compiler exited to high- 
est level before the eof on input file) 

as 42, except warning only, recovery attempted 

FROM-TO-BY-DO out of order in INCR/decR expression 

empty DO part, may not be defaulted in INCR/deCR expression 

empty condition in if-then-else not permitted 

missing THEN 

empty FROM, TO, or BY expression in incr/decr 



number of levels in escape expression is not a literal 

missing ']' in number levels part of an escape expression 

empty expression not permitted as pointer-pointer in special function 

missing ')' in a special function 

missing 'OF' in select expression 

missing or misplaced 'NSET' in select expression 

labeling expression of nset-element may not be empty 

missing or misplaced ":" in a SELECT expression 



missing or misplaced TESN in select expression 
empty elist element in SELECT expression 
'SET' is not an allowed stmt beginner 

No • ( ' after EXCHJ 

Empty new-base expression in EXCHJ 

Missing ')' in EXCHJ 

Missing AT in CREATE 

Missing AT-expression or LENGTH in CREATE 

Missing LENGTH-expression or THEN in CREATE 

Missing '(' after CREATE 



D.3 



D 



NtMBER 



MESSAGE 



74 

75 

76 

77 

100 

101 

103 

104 

105 
•i 
106 



* 



126 

i 

127 
130 

i 

131 

i 

132 

134 
135 
136 
137 
140 

142 
143 
144 
145 
146 
147 
150 
170 
171 
172 



II. II 



symbol to be declared is not an identifier 

missing "*" on a routine, function, or structure declaration 

missing formal parameter list right delimiter, i.e., ")"|"]"|"," 

missing right bracket on the size portion of a "namesize" 

missing delimiter on a list, i.e., "," or 

missing ")" on a name par. 



missing "«" in a machop declaration 

missing "," | ":" | ";" in allocation declaration 

structure access not to an identifier, e.g., l[€]t 'vector' assumed 

register is neither reserved or 'system' type,, see MODULE declaration 

register value out of range (0-15) 

register number is not a literal 

attempted structure access to a variable which has not been mapped, 
^vector assumed *^^ ' 

extra incarnation actuals. ..ignored 

size expression must not be a block 

symbol may not be addressed, and hence may tujt be mapped 

invalid expression in a FORWARD declaration 

invalid expression in a MACHOP declaration 

may not map a symbol of this type 

attempting to map onto an undeclared structure 

incarnation actual or resulting size expression is not a literal 

symbol previously declared in the current context (blocklevel) 
invalid attempt to escape from routine or function 
warning: using a temporary register may invalidate code 
register position of a machine op. must be reg name or literal 



illegal macro name 

empty formal list in macro definition 

more than 31 formals in macro formal list 



J 



''•^-—^ 



Warning iressage, not fatal 



D.4 



NUMBER 



173 
174' 
175' 
176' 

mi 

111 

im 
201 

250 
300 
350 
400 
450 
500 
600' 
613 
614 
615 
616 
617 
620 

622 
623 
624 
625 
626 
627 
630 
631 
632 
633 
634 



MESSAGE 



illegal formal parameter 

macro definition during macro expansion suppressed 

recursive macro call 

macro in use at block purge time 

"(" missing on macro call 

missing exponent on floating constant: fi assumed 

compile time (floating) division by zero 



module declaration within module body 

stack declaration not own, global or external 

stack syntax error (pointer is accurate) 

stack length invalid 

trying to reserve a register in use already 

special register reg num* not valid 

trying to declare a special register already in use 

module errors; compilation starts at pointer 

reserved+special+declarable exceeds 12 — reservation ignored 

missing equals in special reg. 

module declaration errors with a trivial program 

syntax errors in entries switch 

declared entry point is not defined 

plit missing, right paren 

compile time expression error 

load time expression error 

negative plit duplication factor 

may not use long string in this context 






o 



NUMBER E5SAGE 

760 no temporary register available 

761 no declared registers available (INCR/deCR) 

762 no declared registers available (declaration) 
763 

764 
765 
766 
767 overlay compiler error in attempt at overlay 

770 > 100 attempts made to expand space and failed 

771 gt savef overflow 



772 reg, table use field overflow 



report these 
errors to the 



773 graph table UCCF overflow > implementorsl 

774 literal table capacity exceeded 

775 pointer table capacity exceeded ^ 

776 operand pair without intervening delimiter \^ 

777 compiler error 

Note: on some errors related to internal consistency 
checks the compiler may 'punt-~that is, print 
an error message, abort compilation, and return 
to the user with an "*", These errors should 
always be reported to the implementors. 
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